Linking Eternity: A Blockchain-Based Framework for Verifiable and Privacy-Preserving Digital Inheritance

Abstract

The proliferation of digital assets has catalyzed a profound decoupling between intangible property and traditional inheritance jurisprudence. Under the existing legal framework in Taiwan, practitioners must rely on the testamentary forms prescribed in Article 1189 of the Civil Code, which are fundamentally ill equipped to handle cryptographic assets. Specifically, Notarized Wills (Article 1191) necessitate full disclosure to a notary, creating a “Privacy–Security Paradox” where revealing private keys exposes assets to misappropriation. Conversely, while Sealed Wills (Article 1192) offer confidentiality, they are plagued by risks of physical degradation and technical non-executability. This study proposes zkWill, an EVM-compatible decentralized testamentary framework designed to bridge these structural gaps. By leveraging Zero-Knowledge Proofs (ZKPs), zkWill achieves a state of “blind compliance,” verifying that a sealed will meets the statutory requirements of the Civil Code without disclosing its underlying content. The system integrates the Permit2 protocol for secure asset migration and combines AES-256 encryption with IPFS to immunize testaments against centralized storage failures. Unlike conventional services that demand custodial trust, zkWill employs decentralized oracles to trigger automated execution, ensuring legacy distribution without compromising wallet private keys. Empirical data from the Arbitrum Sepolia testnet confirms that the framework maintains constant verification efficiency and a judicially resilient audit trail, providing a paradigm that harmonizes legal pragmatism with cryptographic security for digital inheritance.

1. Introduction

1.1. Legal Background and the Emergence of Digital Asset Succession Challenges

1.1.1. Early Practices in Cryptocurrency Inheritance

Historically, in the absence of comprehensive regulatory frameworks, the inheritance of cryptocurrencies was managed primarily through private, ad hoc arrangements. Testators often recorded private keys or mnemonic seed phrases on physical media and stored them in safe deposit boxes as a rudimentary estate-planning method.

However, such manual approaches lack formal legal recognition and introduce significant vulnerabilities, including risks of physical loss, unauthorized access, and irreversible asset theft. These informal mechanisms fail to provide enforceable legal safeguards or systematic security assurances.

1.1.2. The Rise of Specialized Legislation

The regulatory landscape has begun to evolve with the enactment of specialized legislation, most notably the U.S. GENIUS Act of 2025. This milestone has accelerated the global integration of digital assets into formal estate planning frameworks and increased demand for standardized, secure, and legally recognized inheritance mechanisms.

In contrast, jurisdictions such as Taiwan currently lack a dedicated legal regime governing the succession of virtual assets. Consequently, legal practitioners must rely on traditional testamentary structures under the Civil Code to effectuate the transfer of digital wealth.

1.2. Traditional Testamentary Forms Under Taiwan Law

1.2.1. Statutory Will Formats

Pursuant to Article 1189 [1] of the Taiwan Civil Code, a will may be executed through one of five statutory forms:

Holographic Will—Entirely handwritten, dated, and signed by the testator.

Notarized Will—Orally declared before a notary in the presence of at least two witnesses, authenticated by the signatures of all participants.

Sealed Will—Signed and sealed by the testator and presented to a notary, in the presence of two witnesses, to certify its authenticity as the testator’s true intent.

Dictated (Mystical) Will—Dictated to one witness in the presence of at least three witnesses, followed by signatures or fingerprints of all parties.

Oral Will— Permitted only in emergency circumstances where other forms are infeasible; witnesses record the testamentary intent without the testator’s signature.

While holographic wills are frequently used for routine estate planning, notarized and sealed wills are generally preferred for high-value estates to reduce posthumous disputes.

1.2.2. The Privacy–Security Paradox in Cryptocurrency Succession

When applied to cryptocurrency inheritance, traditional testamentary forms reveal a fundamental privacy–security paradox.

For example, Article 1191 requires that a notarized will be declared before a notary and witnesses. In the context of digital assets, this may require exposing private keys or recovery phrases during execution, thereby creating an unacceptable risk of immediate, irreversible asset misappropriation.

Among the statutory options, the sealed will provides the highest degree of confidentiality. In the landmark Chang Yung-fa [2] case, the court held that a testator needs only to verify the authenticity of the sealed document to the notary, without disclosing its specific contents.

Nevertheless, sealed wills remain suboptimal for digital asset management due to three inherent limitations:

Preservation Risk: Physical documents are susceptible to destruction or loss, and once lost, cannot be recovered.

Security Exposure: Any disclosure of private credentials during execution or probate risks total asset depletion rather than mere information leakage.

Technical Non-Executability: A will may be legally valid but technically unenforceable if it lacks precise on-chain parameters or conflicts with mandatory inheritance rules, such as compulsory portions.

1.3. System Overview: zkWill

To address the challenges of integrity, privacy, and technical executability, this paper proposes zkWill, an EVM-compatible blockchain inheritance system.

The system leverages Zero-Knowledge Proofs (ZKPs) and integrates advanced protocols, including Permit2, CREATE2, and IPFS, to build a legally aligned, cryptographically secure inheritance framework.

The zkWill architecture has been fully implemented, encompassing the following:

Frontend user interfaces, Backend services, Smart contracts, and ZKP circuits.

The system has been successfully deployed on the Arbitrum Sepolia Ethereum Layer 2 testnet.

1.4. Contributions

1.4.1. Primary Contributions

This paper makes the following contributions:

A Privacy-Preserving Blockchain Will System

We propose zkWill, a blockchain-based testamentary system that uses Zero-Knowledge Proofs to preserve confidentiality without requiring users to relinquish control of their wallets.

Legal Compatibility and Regulatory Adherence for Sealed Wills:

zkWill is the first blockchain-based will system whose operational procedures align with the requirements for “Sealed Wills” stipulated under the Taiwan Civil Code. Its adopted “blind compliance” mechanism is consistent with the privacy-preserving and compliant architectural principles advocated in modern regulated enterprise systems [3]. This research demonstrates that in highly regulated environments such as finance and law, the use of modular security controls and automated policy enforcement can effectively balance individual privacy with regulatory compliance needs. This further strengthens the theoretical foundation of zkWill as a compliant solution for digital inheritance.

Automated and Modular Circom [4] Testing Framework:

We design and implement a comprehensive testing framework for Circom circuits, including automated constraint benchmarking.

Open-Source Cryptographic Circuits:

We release multiple open-source Circom circuits, including implementations of AES-256-GCM and optimized Keccak-256.

1.4.2. System Properties

The zkWill framework provides the following system-level guarantees:

Integrity: Only the authenticated testator retains authority to modify testamentary instructions.

Privacy: ZKPs ensure that the will’s contents remain confidential from all parties, including executors, until a verified death event occurs.

Automated Executability: Assets are transferred without exposing private keys, eliminating theft risks while ensuring on-chain enforceability.

Persistence and Transparency: IPFS ensures decentralized storage, while blockchain records provide an immutable audit trail for dispute resolution.

1.5. Organization of Paper

The architecture of this paper is structured to facilitate a progressive technical discourse. We initiate the discussion in Section 1 with a comprehensive introduction that situates the research within the current challenges of digital asset inheritance. Section 2 then delineates the essential Web3 paradigms and cryptographic primitives that form the system’s foundational scaffolding. To provide historical and competitive context, Section 3 synthesizes two decades of digital legacy research, contrasting early centralized heritage services with the emerging frontier of blockchain-integrated systems.

The core methodology is unveiled in Section 4, which deconstructs the system architecture through entity interaction models and a comparative analysis of Zero-Knowledge Proof (ZKP) efficiencies. Technical granularities are further elucidated in Section 5, where we justify the integration of protocols like Permit2 and CREATE2, alongside a rigorous defense of our circuit optimization strategies and automated testing frameworks. The empirical robustness of our approach is validated in Section 6 via cross-layer performance benchmarks. Finally, Section 7 encapsulates our primary contributions and offers a candid interrogation of current limitations, thereby framing a strategic roadmap for future exploration.

2. Background and Related Work

2.1. Blockchain

Satoshi Nakamoto proposed the concept of blockchain in 2008 through the introduction of Bitcoin [5]. As a decentralized distributed ledger technology (DLT), Bitcoin explicitly addresses trust issues in peer-to-peer environments. Its foundational architecture links data blocks chronologically via cryptographic hashes, ensuring data integrity and immutability through a consensus mechanism distributed across multiple nodes.

Owing to its ability to ensure transaction security and consistency without a centralized authority, blockchain initially gained traction in the cryptocurrency domain. Between 2013 and 2014, the emergence of Ethereum, proposed by Vitalik Buterin [6], introduced the paradigm of “smart contracts.” This evolution transitioned blockchain from a rudimentary payment system to a programmable application platform, subsequently catalyzing the growth of decentralized applications (DApps) and decentralized finance (DeFi).

Currently, the blockchain ecosystem witnesses increasing diversification. Beyond the foundational Bitcoin and Ethereum frameworks, a myriad of novel public chains and scaling solutions have emerged to address distinct design objectives. For instance, Solana prioritizes high throughput and low latency, whereas platforms like Sui and Aptos emphasize object-oriented architectures and robust security. Concurrently, Layer 2 scaling solutions (e.g., Arbitrum, Optimism) and sidechains (e.g., Polygon) aim to maintain Ethereum compatibility while significantly reducing transaction costs.

2.2. Smart Contracts

A smart contract is a self-executing programmatic protocol deployed on a blockchain infrastructure that autonomously triggers predefined operations upon the fulfillment of specific conditions. Distinguishing themselves from traditional contractual frameworks, smart contracts obviate the need for centralized intermediaries; the blockchain network’s consensus mechanisms rigorously maintain their execution integrity and immutability. The fundamental characteristics of smart contracts—including automated execution, transparency, and tamper-resistance—facilitate secure transactional workflows and decentralized collaboration among participants, effectively establishing “code-based trust” in the absence of confidence.

2.3. Oracles

Oracles serve as a critical interface bridging the gap between isolated blockchain environments and the external world. They provide a deterministic mechanism for ingesting off-chain telemetry—such as market exchange rates, meteorological data, or financial indices—into the ledger, thereby enabling smart contracts to respond to real-world events. Since blockchain nodes rely on deterministic on-chain data to maintain consensus, oracles have become an essential primitive for Decentralized Applications (DApps). A representative implementation is Chainlink, which leverages a decentralized node network and multi-source data aggregation to ensure data veracity. This decentralized architecture eliminates single points of failure (SPOF) and ensures that smart contract interactions with external environments remain secure and resilient.

2.4. Hash Functions

Hash functions are fundamental cryptographic primitives in smart contracts, utilized to ensure data integrity and immutability. These functions are extensively employed for address generation, message authentication, and the construction of Merkle trees. Specifically, the Ethereum Virtual Machine (EVM) utilizes the Keccak-256 (consistent with the conventions of NIST and the Ethereum Yellow Paper) hash function, which is based on the Keccak algorithm originally proposed by Bertoni et al. [7].

It is critical to distinguish that Ethereum’s implementation of Keccak-256 deviates from the FIPS 202 SHA-3 [8] standard subsequently established by NIST. The discrepancy primarily arises from the padding schemes; Ethereum employs the original Keccak padding, whereas SHA-3 utilizes a modified padding suffix to support domain separation. Consequently, identical input strings yield divergent hash outputs across the two implementations. To ensure interoperability and cryptographic consistency within the Ethereum ecosystem, the Keccak-256 implementation must be strictly utilized in lieu of the standardized SHA-3.

2.4.1. Transaction Verification via Merkle Trees

To efficiently verify the inclusion of a transaction T within a block, hash functions are utilized to construct a Merkle Tree. In a binary Merkle Tree, each leaf node represents the hash of a transaction, Hi = keccak256(Ti). Each non-leaf node is the hash of the concatenation of its child nodes:

$$H_{parent} = \mathrm{k}\mathrm{e}\mathrm{c}\mathrm{c}\mathrm{a}\mathrm{k}256(H_{left}\parallel H_{right})$$

This hierarchical structure allows for a “Merkle Proof,” where a specific transaction can be verified against the Merkle Root using only O(log n) hashes, ensuring both data integrity and computational efficiency.

2.4.2. Cryptographic Distinction: Keccak-256 vs. SHA-3

While both Keccak-256 and SHA-3 leverage the foundational “Sponge” construction, their operational incompatibility stems from a subtle yet critical variation in the domain separation suffixes appended to the message M. This distinction is not merely an implementation detail but a fundamental cryptographic departure that dictates the hash output. The Padding Mechanism in Ethereum’s Implementation. In the Ethereum ecosystem, the hashing protocol adheres strictly to the original Keccak proposal. This padding rule, denoted here as $P_{Keccak}$, is defined as follows:

$$M_{padded}=M\parallel 01\parallel 10\times 1$$

By omitting additional domain bits, Ethereum maintains a direct lineage to the initial submission of the algorithm.

NIST’s Structural Alteration (FIPS 202)

Conversely, the NIST-standardized SHA-3 (FIPS 202) introduces a specific two-bit suffix (01) for domain separation, intended to distinguish SHA-3 from other Keccak-based derivatives (like SHAKE). This results in a distinct padding sequence:

$$M_{padded}=M\parallel 0110\parallel 10\times 1$$

Critical Implications for Smart Contract Architecture

This bitwise discrepancy creates a non-trivial collision: for any non-null message $M$, it is mathematically certain that $keccak256\ne SHA3\left(M\right)$.

Within the context of Solidity-based smart contract development, this necessitates precise opcode selection. A failure to explicitly invoke keccak256 can lead to catastrophic failures in signature verification or the derivation of contract addresses, as the underlying Ethereum Virtual Machine (EVM) is hard-coded to recognize the pre-standardization Keccak-256 variant.

2.5. Cryptographic Foundation: The ECDSA Framework in Ethereum

Within the architectural confines of Ethereum and its peer-to-peer decentralized counterparts, the dual imperatives of transaction integrity and rigorous authorization are upheld by the Elliptic Curve Digital Signature Algorithm (ECDSA) [9]. Unlike broader implementations of elliptic curve cryptography, Ethereum specifically adopts the secp256k1 curve—a choice that offers optimized computational efficiency and a well-defined cyclic group structure.

The Mechanics of Key Derivation and Signing

At the heart of this cryptographic primitive lies the asymmetric key pair (d, Q). The private key, d, is defined as a stochastically generated integer within the field $F_n$ whereas the corresponding public key, Q, is derived through scalar point multiplication:

$$Q = d \times G$$

represents the curve’s predefined generator point. When an actor initiates a state transition (a transaction), they produce a signature pair (r, s) by leveraging their private key against the message hash. This process ensures that the resulting signature is mathematically tied to the specific entropy of the private key without exposing it. Verification and Security Posture: The validation process executed by network nodes is not merely a technical check but a three-fold security guarantee. Data Integrity & Authenticity: By verifying the (r, s) pair against the public key Q, the protocol ensures the payload has remained immutable post-signing and confirms the provenance of the message as originating from the legitimate account holder. Non-repudiation: The deterministic nature of the ECDSA verification ensures that once a transaction is broadcast and validated, the signer cannot plausibly deny its execution. The robustness of this scheme is anchored in the Elliptic Curve Discrete Logarithm Problem (ECDLP). Given the current state of classical computational complexity, the inversion of the point multiplication—deriving d from Q—remains computationally intractable, thereby preserving the sub-linear security margin required for long-term blockchain persistence.

2.6. Taxonomy of Symmetric Block Cipher Operational Modes

Symmetric-key cryptography, characterized by the utilization of a singular, shared secret for both bidirectional cryptographic transformations, remains a cornerstone of high-throughput data protection in blockchain infrastructures. While algorithms such as the Advanced Encryption Standard (AES) provide the underlying primitive, their practical security and performance are dictated by the Operational Mode—the specific strategy for processing plaintext blocks.

The Evolution from Static to Authenticated Encryption

The selection of an operational mode involves a critical trade-off between parallelizability, error propagation, and data confidentiality:

• The Vulnerability of Electronic Codebook (ECB): As the most rudimentary approach, ECB encrypts blocks in isolation. This lack of inter-block dependency fails to obscure data patterns, rendering it susceptible to frequency analysis and pattern-based leakage. Consequently, its deployment is strictly deprecated in modern IEEE-compliant security frameworks.
• Sequential Diffusion in Cipher Block Chaining (CBC): To remediate ECB’s transparency, CBC introduces a chaining mechanism where each plaintext block is XORed with the preceding ciphertext. While this provides superior diffusion, it imposes a strictly sequential processing bottleneck, hindering hardware acceleration in high-latency environments.
• Parallelism via Counter Mode (CTR): By transforming a block cipher into a deterministic stream cipher, CTR mode encrypts successive counter values rather than the message itself. This decoupling allows for full parallelization, a vital requirement for high-throughput distributed systems requiring rapid state synchronization.
• The GCM Gold Standard (AEAD): Galois/Counter Mode (GCM) represents the contemporary industry benchmark. Beyond mere confidentiality, GCM integrates a Galois field multiplier to provide Authenticated Encryption with Associated Data (AEAD). This integration ensures that any unauthorized alteration of the ciphertext or the associated metadata (e.g., header information) results in a verification failure via a Message Authentication Code (MAC).

Computational Overhead and Integrity Constraints

While the spatial complexity of the ciphertext generally maps linearly to the plaintext, subtle overheads are introduced by architectural requirements. These include the PKCS#7 padding required for block alignment in CBC, or the 128-bit authentication tag generated in GCM. In professional cryptographic implementations, these “tags” are indispensable for ensuring that data integrity is not sacrificed for raw encryption speed.

2.7. Taxonomy and Programmability of On-Chain Assets

On-chain assets represent a paradigm shift in value representation, where ownership and transfer logic are natively embedded within a blockchain’s state machine. Rather than acting as mere digital pointers, these assets are cryptographic primitives governed by standardized smart contract interfaces, categorized by their functional logic and economic properties.

2.7.1. Architectural Standards: Fungibility and Interoperability

The distinction between asset classes is primarily dictated by the degree of interchangeability and the underlying data structures:

Fungible Tokens (ERC-20): As the most pervasive framework within the Ethereum ecosystem, the ERC-20 standard codifies a uniform set of rules for mutually interchangeable units. By implementing a standardized interface for transfer mechanisms and allowance logic, ERC-20 facilitates seamless integration across Decentralized Finance (DeFi) protocols. These tokens serve as the liquidity backbone for stablecoins and governance frameworks, where each unit’s value is mathematically identical to any other.

Non-Fungible Tokens (NFTs) and Hybrid Multi-Tokens: In contrast to the uniform nature of ERC-20, NFTs introduce unique, indivisible identifiers.

ERC-721 [10]: Establishes a strict one-to-one mapping between a unique uint256 token ID and an owner’s address, enabling verifiable scarcity for digital intellectual property and virtual real estate.

ERC-1155 [11]: Operates as a more sophisticated evolution, allowing a single deployed contract to manage an arbitrary constellation of both fungible and non-fungible assets. This “multi-token” approach significantly reduces gas costs and complexity for applications requiring diverse asset types, such as gaming ecosystems or complex financial derivatives.

2.7.2. Real-World Assets (RWAs) and the TradFi Convergence

A critical frontier in blockchain adoption is the tokenization of Real-World Assets (RWAs)—the process of mapping tangible or intangible off-chain value (e.g., sovereign debt, private equity, or physical commodities) onto a programmable ledger.

While fiat-collateralized stablecoins (e.g., USDT, USDC) technically represent a subset of on-chain fiat reserves, the academic and technical literature increasingly distinguishes RWAs as a broader category of complex asset classes. The primary value proposition of RWAs lies in fractionalization and on-chain transparency, which democratize access to previously illiquid markets. By bridging Traditional Finance (TradFi) with decentralized infrastructure, RWAs facilitate the “programmability of collateral,” allowing physical assets to be utilized in automated lending and credit protocols without intermediary friction.

2.8. Consensus Algorithms

Consensus algorithms are the foundational protocols that ensure distributed nodes reach a synchronized state in a Byzantine environment. The evolution of consensus mechanisms reflects a shift from computational intensity to capital-based security:

• Proof of Work (PoW): Originally implemented in Bitcoin, PoW requires nodes (miners) to solve a computationally expensive cryptographic puzzle (hash inversion). While it offers high security and decentralization, its primary drawbacks include significant energy consumption and limited throughput, characterized by a low Transactions Per Second (TPS).
• Proof of Stake (PoS): Adopted by Ethereum 2.0, PoS replaces energy-intensive mining with a staking mechanism. Validators are selected based on the quantity of native currency they “stake” as collateral. This design significantly reduces the network’s carbon footprint and enables the implementation of scaling solutions, such as sharding.
• Byzantine Fault Tolerance (BFT) Variants: Protocols such as Practical Byzantine Fault Tolerance (pBFT) and Tendermint achieve consensus through multiple rounds of voting among a fixed set of validators. These algorithms emphasize finality by guaranteeing that a committed block is irreversible.

Selecting a consensus algorithm involves a trade-off among the three pillars of the Blockchain Trilemma: Security, Scalability, and Decentralization.

2.9. Decentralized Finance (DeFi)

Decentralized Finance (DeFi) represents an experimental financial subsystem that leverages smart contracts on public blockchains to replicate traditional financial services without central intermediaries. The DeFi ecosystem is characterized by composability, often called “Money Legos”, which enables the integration of multiple protocols to create complex financial products. Key components include the following:

• Automated Market Makers (AMMs): Protocols like Uniswap” utilize mathematical formulas such as the Constant Product Formula $x \times y = k$ to facilitate permissionless token swaps. AMMs replace traditional order books with Liquidity Pools, allowing users to trade directly against a smart contract.
• Over-collateralized Lending: Platforms such as Aave and Compound enable decentralized borrowing and lending. To mitigate the risk of default in a pseudonymous environment, borrowers must provide collateral that exceeds the loan amount (e.g., a Loan-to-Value (LTV) ratio).
• Yield Farming and Liquidity Mining: These are incentive mechanisms where users provide liquidity to protocols in exchange for governance tokens, effectively bootstrapping the network’s liquidity and user base.

The primary advantages of DeFi include permissionless access, 24/7 market availability, and on-chain transparency. However, it also networks unique risks, such as Smart Contract Vulnerabilities, Impermanent Loss, and Oracle Manipulation.

2.10. Permit Mechanism (ERC-2612)

The Permit mechanism, formalized under the ERC-2612 standard [12], is an extension of the ERC-20 token standard designed to optimize the authorization workflow and improve user experience.

In the conventional Approve-then-TransferFrom model, a user must execute an on-chain approve (spender, amount) transaction to grant a specific smart contract permission to transfer their tokens. Subsequently, the contract invokes transferFrom() to perform the actual transfer. This dual-transaction process is inefficient, as it incurs cumulative Gas fees and requires the user to possess native network tokens (e.g., ETH) for transaction execution.

The Permit mechanism leverages off-chain signature authorization to streamline this process. Based on the EIP-712 structured data hashing standard, the workflow is as follows:

• Off-chain Signing: The user generates a digital signature on a structured message containing parameters such as the owner, spender, value, nonce, and deadline. This action is performed off-chain and does not consume gas.
• On-chain Verification: The signed message is submitted to the permit () function by a relayer or the target contract.
• State Update: The contract verifies the signature using the ECDSA. Upon successful verification, the system updates the allowance within the same transaction as the subsequent business logic.

This mechanism not only mitigates UX friction from multiple transactions but also enables “gasless” interactions for the user, as the gas fees for the permit() call can be subsidized by the service provider or rolled into a single atomic transaction.

2.11. InterPlanetary File System (IPFS)

The InterPlanetary File System (IPFS) [13] is a peer-to-peer (P2P) distributed file system designed to replace the traditional location-based addressing of the Hypertext Transfer Protocol (HTTP) with content-addressable storage. In the IPFS framework, IPFS decomposes files into smaller data blocks and assigns each block a unique cryptographic hash, ensuring data immutability. Nodes within the network utilize a Distributed Hash Table (DHT) to locate and retrieve these blocks, thereby eliminating single points of failure associated with centralized servers.

A Content Identifier (CID) serves as the self-describing label for a specific piece of content. Any infinitesimal modification to the underlying data results in a distinct CID, facilitating inherent version control and verification. According to the IPFS specification, a CID is composed of three primary components:

• Version: Indicates the CID format, such as CIDv0 (the original base58-encoded format) or CIDv1 (a more flexible, binary-friendly version).
• Codec: Specifies the data encoding format (e.g., dag-pb or json) so the system can correctly interpret the content.
• Multihash: Represents the output of a cryptographic hash function (typically SHA-256) encapsulated in a format that identifies the algorithm used.

Consequently, the CID represents the cryptographic fingerprint of the content rather than its physical or network location. This architecture ensures high levels of verifiability and persistence, making it a foundational layer for decentralized applications (dApps) and NFT metadata storage.

Furthermore, empirical analysis from the recent literature indicates that decentralized storage models can effectively supersede traditional Centralized Third-Party Auditors/Authorities (TPAs/TAs). By enhancing system reliability and stability, these models leverage the immutability of blockchain to achieve comprehensive data traceability management.

In parallel, related research emphasizes that blockchain technology is fundamentally transforming information-sharing paradigms by eliminating intermediaries and establishing trust within decentralized ecosystems. In such frameworks, blockchain facilitates a secure and transparent recording system where data—such as energy consumption statistics—is protected by cryptographic hash functions (e.g., SHA-256) once committed to the ledger. This mechanism aligns seamlessly with the logic of the zkWill framework, which employs IPFS Content Identifiers (CIDs) as encrypted fingerprints. Both approaches aim to mitigate single points of failure (SPOFs) through distributed storage, providing superior reliability, transparency, and data integrity when managing sensitive information, such as energy trends or digital legacies.

2.12. Zero-Knowledge Proof (ZKP)

Zero-Knowledge Proof (ZKP) is a sophisticated cryptographic primitive first conceptualized in 1985 and formally published in 1989 by Goldwasser, Micali, and Rackoff [14]. A ZKP protocol enables a Prover to demonstrate the validity of a specific assertion to a Verifier without disclosing any underlying data or witnesses associated with the statement. For a protocol to be classified as a ZKP, it must rigorously satisfy three fundamental properties:

• Completeness: If the statement is true, an honest Verifier will be convinced by an honest Prover with overwhelming probability.
• Soundness: If the statement is false, no malicious Prover can convince an honest Verifier, except with a negligible mathematical probability.
• Zero-Knowledge: The verification process yields no information to the Verifier beyond the fact that the assertion is indeed true.

While ZKP technology is inherently a mathematical construct independent of distributed ledgers, it has become a cornerstone for enhancing privacy and scalability in modern blockchain ecosystems.

2.12.1. Merkle Tree Construction

Privacy-centric protocols, most notably Zcash [15,16,17], implement ZKPs—specifically zk-SNARKs (Succinct Non-Interactive Arguments of Knowledge)—to ensure the confidentiality of transaction metadata, including sender/receiver addresses and transaction magnitudes. The well-known mixer Tornado Cash [18] is also based on ZKP technology. Beyond financial applications, ZKPs are instrumental in electronic voting (e-voting) systems. Research by Tarasov and Tewari [19] and Banerjee [20] proposed frameworks utilizing Zcash’s architecture for anonymous ballot casting. Furthermore, Huber et al. [21] investigated the verification of encrypted ballots using Exponential ElGamal encryption, while the Minimal Anti-Collusion Infrastructure (MACI) [22] leverages ZKPs to mitigate collusion risks in decentralized governance.

2.12.2. ZKPs for Blockchain Scalability

In the domain of performance optimization, zk-Rollups have emerged as a dominant Layer 2 (L2) scaling solution. Ethereum-based implementations, such as zkSync, Polygon zkEVM, Scroll, StarkNet, Linea, and Taiko, utilize zk-SNARK or zk-STARK (Scalable Transparent Arguments of Knowledge) protocols to offload execution from the mainnet.

These zk-Rollups aggregate extensive off-chain computations into a single, succinct on-chain proof, thereby substantially reducing gas costs and increasing Transactions Per Second (TPS). By condensing thousands of transactions into a unified proof, zk-Rollups minimize the on-chain data footprint while maintaining L1-level security.

Critically, unlike Optimistic Rollups, zk-Rollups provide near-instant finality because the validity of state transitions is enforced by mathematical proofs rather than dependent on a time-consuming fraud-proof challenge period.

3. Related Works

3.1. Academic Progress and Evolution

The academic exploration of digital wills began with Chien et al. [23], who in 2009 investigated the feasibility of digitalizing testamentary instruments within the legal framework of Taiwan. Their study established a foundational cryptographic framework for sealed wills but relied on a centralized Trusted Authority (TA), such as a court of law, to manage encryption keys. To address practical implementation challenges, Lee et al. [24] refined this model by integrating the Government Public Key Infrastructure (GPKI). Subsequently, Chen et al. [25] introduced a privacy-enhanced iteration where the TA was restricted to data transmission and custodial roles. In this scheme, decryption required the collective participation of the testator’s heirs through a secret sharing mechanism, ensuring that no single party could access the entire document prematurely.

Despite these advancements, these early studies primarily focused on the digitization of traditional sealed wills—prioritizing content confidentiality and key management over the automated execution of assets. In the context of decentralized on-chain assets, a critical tension arises between executability and private key security. While a TA must be empowered to execute the will upon the testator’s demise, granting them full access to a wallet’s private key introduces significant custodial risk and the potential for misappropriation. Consequently, traditional key-handover methods are unsuitable for blockchain environments, necessitating the use of smart contracts.

In 2017, Sreehari et al. [26] proposed a smart contract-integrated system; however, their model assumed a fully blockchain-native legal ecosystem, which remains impractical under current jurisdictional constraints. Within Taiwan, Chen et al. [27] developed a smart contract-based framework featuring non-repudiation and an arbitration mechanism for dispute resolution. Nevertheless, their approach faced significant limitations: storing encrypted wills directly on-chain is cost-prohibitive (gas-inefficient), and the requirement for manual judicial review compromises the strict confidentiality standards of sealed wills.

More recently, Seres et al. [28] formalized the security properties of cryptographic wills via the CryptoWills protocol. This protocol utilizes Trusted Execution Environments (TEEs), Threshold Secret Sharing, and Time-Lock Puzzles (TLPs) to manage static and dynamic bequests. However, CryptoWills relies on a time-based trigger as a proxy for death, a mechanism that is legally inadmissible in Taiwan, where statutory probate procedures require a formal certificate of death. Similarly, WillChain, proposed by Pharr in 2025 [29], offers a highly modular Layer-1 blockchain solution with cross-chain interoperability and robust privacy. Yet WillChain shares the same legal drawback as its predecessors: its reliance on automated, time-based triggers fails to align with the formalistic requirements of Taiwan’s Civil Code.

As summarized in

Table 1. Summary of Prior Studies on Digital Wills.

Year	Paper	Assumptions or System Characteristics
2009	The Study of Secure E-will System on the Internet	Proposed the first cryptography-based framework for digital wills in Taiwan and assumed a Trusted Authority (e.g., a court) to safeguard encryption keys.
2010	A Practical Approach to a Secure E-Will System in the R.O.C.	Improved the original framework by incorporating the GPKI for practical deployment.
2011	A private online system for executing wills based on a secret sharing mechanism	Limited the court to transmitting and safeguarding encrypted wills, while decryption required partial contributions from multiple family members.
2017	Smart will converting the legal testament into a smart contract	Integrated wills with smart contracts and assumed that all legal transactions would be executed entirely on the blockchain.
2020	CryptoWills: How to Bequeath Cryptoassets	Proposed the CryptoWills protocol with time-based execution triggers using TEE, TSS, HD wallets, and Time-Lock Puzzles.
2021	A Traceable Online Will System Based on Blockchain and Smart Contract Technology.	Proposed a smart contract-based will system with integrity and non-repudiation but stored encrypted wills directly on-chain with manual court review.
2025	Willchain: Decentralized, Privacy-Preserving, Self-Executing, Digital Wills	Proposed WillChain as a L1 blockchain supporting privacy and cross-chain interoperability with time-based execution triggers.

, existing literature often necessitates a trade-off between privacy, decentralization, and legal compliance. Previous works either depend on highly centralized entities or adopt automated triggers that bypass mandatory probate laws. In contrast, this study proposes a trustless verification mechanism that ensures the executability of on-chain assets without sacrificing privacy, while remaining strictly compliant with the legal prerequisites of sealed wills in Taiwan.

3.2. Practical Landscape: From Legacy Systems to the On-Chain Gap

While the global shift toward digital legacy management has accelerated, the legal and technical implementation remains highly fragmented. As of 2025, Taiwanese jurisprudence maintains a conservative stance [30], refusing to grant formal validity to purely digital wills—a sharp contrast to the legislative experimentation seen in several U.S. jurisdictions. This regulatory divergence has nonetheless fueled a burgeoning market for Estate Management as a Service (EMaaS). These platforms aim to govern “digital estates,” a term popularized by UNESCO [31] to encapsulate the shift from tangible heirlooms to intangible, yet high-value, digital assets: cloud-based repositories, social media identities, and increasingly, cryptographic wealth.

However, a critical evaluation of current market leaders reveals a functional superficiality regarding the unique demands of decentralized assets:

• Digitalwill.com: Relies on a traditional delegation model, where the testator assigns tasks to executors via standard encryption. While it digitizes the workflow, it remains bound to centralized trust.
• LifeLedger: Focuses on the logistical burden of death, offering automated notification services. It serves more as a bureaucratic lubricant than a secure vault for value transfer.
• Big Tech Interventions (Apple, Meta, Google): Solutions like Legacy Contacts or Google’s Inactive Account Manager represent a proprietary approach to “digital mortality”. These are limited by ecosystem silos; they manage access to platform-specific data but offer no bridge to assets residing outside their walled gardens.

The Security–Sovereignty Paradox

The fundamental tension in existing services lies in their structural incompatibility with on-chain assets. Most current “digital will” providers are optimized for off-chain, centralized data, failing to account for the non-custodial imperatives of Web3. To utilize these services for cryptocurrency or NFTs, users are often forced into a catastrophic security trade-off: disclosing private keys to a third-party intermediary.

This introduces an unacceptable layer of custodial risk and administrative moral hazard. Relying on a provider’s integrity—a “trusted” third party—diametrically opposes the foundational ethos of blockchain. There is, therefore, a glaring void in the market for a non-custodial, smart contract-driven framework. Such a solution must bypass the frailties of human intervention, ensuring that the transfer of on-chain wealth is not only secure but fundamentally trustless.

4. System Design: The zkWill Framework

To address the aforementioned security–trust paradox, we introduce zkWill—a decentralized, privacy-preserving testamentary protocol that synthesizes Zero-Knowledge Proofs (ZKPs) with distributed ledger technology. Unlike existing SaaS solutions that necessitate custodial trust, zkWill is architected to mirror the “sealed will” requirements of the Civil Code, yet it operates within a purely trustless environment.

The ecosystem is underpinned by five functional archetypes: the testator, a minimum of two witnesses, a notary, an oracle, and an executor, alongside the designated beneficiaries. While the human roles (testator, witnesses, notary) are direct digital analogs to their statutory counterparts, the oracle represents a pivotal technical intervention. It functions as a non-human, verifiable source of truth, specifically tasked with providing an immutable “proof of death” without compromising the testator’s pre-mortem privacy.

These actors operate across four non-linear phases—Upload, Notarization, Probation, and Execution—orchestrated via the interplay between Ethereum-compatible smart contracts and the InterPlanetary File System (IPFS). This lifecycle is designed to ensure that the will remains a “black box” during the testator’s lifetime, only transitioning to an executable state upon cryptographically verified triggers.

4.1. Architectural Layers and Cryptographic Enforcement

The structural integrity of zkWill, as conceptualized in Figure 1, relies on the modular decoupling of storage, computation, and consensus.

The Storage and Blockchain Layers

The Storage Layer utilizes IPFS to move sensitive testamentary data off chain, mitigating the high costs and transparency risks of blockchain storage. Each encrypted will is indexed via a unique Content Identifier (CID), ensuring that while the data are immutable and globally accessible, their content remains obfuscated to all but the authorized decryption keys.

The Blockchain Layer acts as the system’s “judicial engine”, comprising several specialized Solidity contracts:

• WillFactory.sol: The primary gatekeeper. It does not merely store data but validates the cryptographic integrity of incoming CIDs and their associated ZKPs.
• The Verifier Suite: To maintain a high degree of modularity, we employ specialized verifiers—JsonCidVerifier.sol (for structural metadata validation), and CidUploadVerifier.sol alongside WillCreationVerifier.sol. These contracts perform the heavy lifting of ZKP verification, ensuring that the testator’s claims (regarding asset ownership and witness participation) are mathematically valid without revealing the underlying data.
• Will.sol: Upon the successful validation of the “death trigger” by the oracle, the factory deploys an autonomous Will.sol instance. This contract serves as a self-executing escrow, programmatically distributing on-chain assets to beneficiaries, thereby bypassing the risks of executor malfeasance.

Frontend Interfacing and Backend Circuitry

The frontend serves as the multi-tenant gateway, managing the complex data flows between the user, IPFS, and the Ethereum Virtual Machine (EVM). Currently, the generation of ZKPs is handled by a Circom-based backend. In this pilot implementation, the frontend relays circuit inputs to the backend, which computes the witness and generates the proof for on-chain submission.

However, we must acknowledge a critical security consideration: for a production-level deployment, this backend must be transitioned into a Trusted Execution Environment (TEE) or executed locally on the client-side. This shift is essential to eliminate the “prover-trust” bottleneck, ensuring that even the proof generation process remains shielded from potential interception or manipulation. By separating the computation of proofs from the on-chain verification, zkWill achieves a rare equilibrium between absolute privacy and automated legal enforcement.

4.2. Workflows

4.2.1. Overview

Figure 2 illustrates the interactions among the entities within the zkWill framework. In this architecture, the testator designates an executor to facilitate the transfer of on-chain assets to the beneficiaries. The testamentary document is protected via symmetric encryption using a key shared between the testator and the executor, resulting in a digitally sealed will.

The system subsequently uploads the encrypted file to IPFS, generating a Content Identifier (CID) that it records on the blockchain. A zero-knowledge proof (ZKP) then verifies the authenticity of the testator’s digital signature within the sealed envelope without disclosing its contents.

While the ZKP ensures the technical feasibility of the digital will, the notarization phase guarantees its legal enforceability. Upon the recording of the CID on chain, the notary and witnesses—designated in accordance with Article 1198 of the Civil Code—must notarize the CID to formalize the instrument.

The executor, equipped with the CID and the shared encryption key, retains the capability to retrieve and decrypt the will. To ensure inheritance distribution strictly follows the testator’s intent, zkWill transforms the digitally sealed will into a smart contract. This contract is exclusively triggerable by the designated executor, thereby upholding two fundamental security principles:

• Access Control: Restricting the management of the inheritance to authorized entities.
• Operational Constraint: Limited flexibility in the methodologies available for asset management.

However, this architecture does not natively enforce a temporal constraint (i.e., when the transfer can occur). A potential vulnerability exists where an executor might collude with a beneficiary to prematurely execute the asset transfer while the testator is still alive. To mitigate such risks, prior implementations such as CryptoWills and WillChain use periodic “heartbeat” actions; however, such time-based mechanisms remain legally insufficient for determining death in most jurisdictions.

To align with established legal frameworks, the asset transfer must be contingent upon a formal legal confirmation of the testator’s demise.

Given the empirical complexity of death verification, the system delegates this responsibility to an external oracle representing a trusted real-world entity (e.g., a hospital or government agency).

This oracle “probates” the sealed will by providing verified proof of death. Following this probation, the executor deploys the Will contract, accompanied by a secondary ZKP verification to prevent the submission of fraudulent testamentary data. Upon successful deployment, the executor invokes the contract to finalize the estate distribution. Throughout this lifecycle, beneficiaries remain passive recipients, preserving the confidentiality and unilateral nature inherent to a sealed will.

The technical core of the zkWill system is anchored by a pre-deployed WillFactory contract on an EVM-compatible blockchain. The WillFactory serves as the primary orchestration layer, encompassing the following core functionalities:

• predictWill(): This function computes the deterministic address of a future Will contract based on the testator’s address, an estate list, and a specific salt value. By leveraging the CREATE2 opcode, the system allows for the pre-computation of contract addresses prior to actual deployment.
• uploadCid(): This function enables the testator to upload the Content Identifier (CID) of the sealed will to the blockchain. It concurrently verifies, via a Zero-Knowledge Proof (ZKP), that the file contains a valid digital signature originating from the testator. Access to this function is strictly restricted to the testator.
• notarizeCid(): This function facilitates the formal notarization of an uploaded CID by the notary. It requires the submission of digital signatures from at least two witnesses to validate the CID, and access is restricted exclusively to the notary.
• probateCid(): This function permits the oracle to perform the “probate” action on a notarized CID. The function is restricted to authorized oracle entities to confirm the legal passing of the testator.
• createWill(): This function enables the executor to instantiate the actual Will contract based on a probated CID. The contract is deployed via the CREATE2 opcode to ensure the address matches the previously predicted value. Prior to instantiation, a secondary ZKP is verified to guarantee the integrity of the off-chain decryption process.

During the initialization phase of the WillFactory, the addresses for the JsonCidVerifier and the two specialized ZKP verifier contracts must be provided as constructor parameters. All subsequent validations of CIDs and ZKPs are delegated to these external, modular verifier contracts to ensure system extensibility.

Once successfully deployed, the individual Will contract exposes a singular, critical executable function:

• signatureTransferToBeneficiaries(): This function executes the transfer of the testator’s assets in strict adherence to the immutable parameters defined within the contract. Authorization for this function is restricted solely to the designated executor.

The comprehensive Solidity implementation for both WillFactory.sol and Will.sol is available via a public GitHub repository [32].

The permissions for each role in the system are described in

Table 2. This table presents the function list of the DID-Chain smart contract.

Permissions	Creation	Read	Notarization	Update	Revocation	Probation	Execution
Testator	✔	✓	▲	✓	✓
Witness			▲
Notary			✓
Oracle						✓
Executor			△				✓
Beneficiary

△: Although in our system the encryption and decryption keys are directly entrusted to the executor, various practical approaches exist to prevent the executor from arbitrarily accessing the will (see Section 7.2.4 for details). ▲: By law, the testator and witnesses are required to participate in the notarization process during the testator’s lifetime. ✓:The symbol "✓" denotes that a specific role is granted the authorization to execute a function or is permitted to perform a designated operation.

. We assume that the wallet’s private key is not included within the will itself. Consequently, while the executor is granted read access to the will, it has no authorization to modify, revoke, or execute the will.

4.2.2. Details

Phase 1: Testator Lifecycle—Drafting, Encryption, and Zero-Knowledge Anchoring

The inception of the zkWill lifecycle begins with the testator’s synthesis of a structured legal instrument. This digital document is not merely a list of assets but a formalized data structure comprising the testator’s address, the designated executor, and witnesses. As evidenced in Figure 3, the “estate” is granularly defined; each entry mandates an ERC-20 token contract address, the specific quantum of transfer, and the beneficiary’s cryptographic identity. To bind these intentions to a verifiable signature, the testator issues a “permit”—a cryptographic authorization that bridges the gap between static intent and executable code (detailed in Section 5.2.1).

The Privacy–Governance Nexus

A notable architectural choice in zkWill is its adaptability to regulatory oversight. By permitting the designation of a tax authority as the executor, the system provides a pathway for institutional estate management, ensuring that asset distribution adheres to inheritance tax obligations.

To safeguard these sensitive data from public exposure, the will undergoes local AES-256-CTR encryption before departing the testator’s environment. We assume a robust key-management framework—leveraging Diffie–Hellman or specialized Key Management Services (KMSs)—to establish a shared secret between the testator and the executor. This “sealed” ciphertext, accompanied by its Initialization Vector (IV), is then relegated to the Inter Planetary File System (IPFS) shown in Figure 4. This off-chain storage strategy is a pragmatic necessity; given the prohibitive gas costs associated with on-chain data persistence, storing the full ciphertext directly on the blockchain would be economically non-viable for complex estates. Instead, the blockchain acts as a ledger of integrity, storing only the Content Identifier (CID) via the uploadCid() function.

Figure 5 illustrates the complete lifecycle of will creation from the testator’s perspective within the zkWill framework. The process begins with the testator drafting a structured digital will, specifying key roles (executor, witnesses) and detailing estate allocations, including ERC-20 token addresses, transfer amounts, and beneficiary identities.

To ensure a precise technical understanding of Figure 5, the visual notation must be interpreted through the lens of standard sequence diagram semantics, representing the temporal movement of data, state transitions, and cryptographic transformations within the zkWill Phase 1 lifecycle.

1. Solid Directional Arrows: Sequential Execution Flow

• The primary solid arrows delineate the active execution path, signifying a synchronous progression where each operation serves as a prerequisite for the subsequent stage:
• From Drafting to Signing: Denotes the transformation of the testator’s subjective intent into machine-readable, cryptographically authorized signatures (Steps 1–6).
• From Signing to Encryption: Indicates the encapsulation of the Permit2 authorization within the data payload (Step 7) prior to the application of AES-256-CTR encryption (Step 9), ensuring the "will" is obscured before transmission.
• From Encryption to On-Chain Anchoring: Represents the migration of the sealed "blob" and its associated metadata (CID and ZKP) from the local client to the DID-Chain (Step 13).

2. Dashed Arrows: Systemic Return Messages

• In contrast to auxiliary inputs, the dashed arrows in this diagram strictly represent Return Signals or asynchronous feedback from the protocol components:
• Address Return: The WillFactory provides the testator with a pre-calculated, deterministic contract address via CREATE2 (Step 4).
• Transaction Confirmation: Signifies the receipt of a "success" status from the blockchain after the network has validated the user’s digital identity and finalized the session (Step 11).

3. Self-Loop Arrows: On-Chain Integrity Verification

• Arrows that cycle back to the same participant (Self-loops) represent internal validation logic executed within the smart contract environment:
• Integrity Checks: These represent the DID-Chain recomputing hashes and validating the Phase 1 ZKP against the anchored CID (Steps 14–15). This ensures that no data corruption occurred during the IPFS upload and that the proof is mathematically sound before the state is committed to the ledger.

4. Environmental Architecture: Implicit Boundaries

• The distinction between execution environments is established through the horizontal positioning of participants (Lifelines) rather than physical boundary lines:
• Off-Chain Domain (Testator): The leftmost section encapsulates private, client-side computations (e.g., drafting and local encryption) where sensitive data remains isolated from the public ledger.
• On-Chain Domain (DID-Chain / WillFactory): The central columns represent the decentralized execution environment where gas-consuming transactions occur.
• Post-Anchoring Key Handover: Crucially, the Key Transfer (Step 16) is depicted as the final operation, occurring only after successful on-chain anchoring. This signifies a private, off-chain handover of the decryption secret to the Executor, ensuring that access control is only delegated once the testamentary record is immutably secured.

Once finalized, the testator cryptographically signs the will by generating a permit, transforming the document from static intent into an executable authorization compatible with smart contract logic.

To preserve confidentiality, the signed will is then encrypted locally using AES-256-CTR. A shared secret key is established between the testator and the designated executor through secure key exchange mechanisms (e.g., Diffie–Hellman or a Key Management Service), ensuring that only authorized parties can decrypt the contents.

Following encryption, the ciphertext—along with its initialization vector (IV)—is uploaded to IPFS for decentralized off-chain storage. This step minimizes on-chain costs while maintaining data availability. Finally, the resulting Content Identifier (CID) is anchored on-chain via a function such as uploadCid(), enabling verifiable integrity without exposing sensitive information.

Overall, the figure captures a pipeline of four key stages, drafting, signing, encryption, and decentralized storage with on-chain anchoring, demonstrating how zkWill balances privacy, cost-efficiency, and verifiability.

The architectural necessity for privacy-preserving and compliant frameworks is further underscored in the recent literature. For instance, research on LLM deployment in regulated enterprise AI systems [33] proposes a modular approach to meet stringent GDPR and HIPAA requirements without sacrificing system utility. This aligns with the zkWill philosophy, where a modular, ZKP-driven architecture is utilized to harmonize the rigid demands of inheritance law with the inherent transparency of blockchain technology, ensuring both statutory compliance and cryptographic privacy.

Cryptographic Integrity and the ZKP Frontier

The JsonCidVerifier contract provides a critical on-chain check-and-balance, recomputing hashes to ensure the CID’s fidelity. However, the system’s true security lies in its Phase 1 ZKP. This proof serves as a mathematical guarantee that the encrypted blob contains a valid signature and all parameters necessary for a future transfer—without ever exposing the underlying plaintext to the public.

A central challenge in this phase is the authorization bottleneck. A primitive design might embed the testator’s private key within the encrypted will, but such an approach is fundamentally flawed. It introduces a catastrophic single point of failure where a compromised executor could unilaterally misappropriate assets. Even the standard approve() function falls short, as it fails to enforce execution constraints or specific beneficiaries.

From ERC-2612 to Permit2: A Shift in Paradigm

To mitigate these systemic vulnerabilities, zkWill utilizes the permit() function (ERC-2612) [12]. This represents a significant shift from legacy “allowance” models:

Digital Sovereignty: Unlike approve(), permit() utilizes off-chain signatures, minimizing the exposure of private keys and incorporating built-in replay protection.

Delayed Disclosure: Authorizations remain off-chain until the probate phase, effectively masking the token types and amounts from pre-mortem surveillance.

Unified Permissions: Our implementation adopts Permit2, an evolution of the standard that allows for batch transfers and unified permissions across disparate contracts.

As illustrated in Figure 6, while generating these ZKPs is computationally expensive—often requiring several minutes of high-intensity processing—this temporal cost is a deliberate trade-off. It secures a future where the testator’s assets remain locked in a “silent” yet programmatically certain state until the legal criteria for distribution are met.

Phase 2: Notarization—The Legal–Cryptographic Synthesis

Once the testator’s CID has been anchored and the Phase 1 Zero-Knowledge Proof (ZKP) successfully validated, the system transitions into the Notarization Phase. This stage is not merely a technical checkpoint but a digital translation of physical probate requirements. To align with the stringent mandates of the Civil Code—which demands the contemporaneous presence of the testator, a notary, and at least two witnesses for a sealed will—the zkWill protocol mandates a Multi-Signature (Multi-Sig) Validation Protocol.

Figure 7 depicts the notarization phase, where the zkWill protocol formalizes the will through a legally compliant, multi-party validation process. Following the successful anchoring of the Content Identifier (CID) and verification of the Phase 1 Zero-Knowledge Proof (ZKP), the system advances into a stage that mirrors the procedural rigor of traditional sealed wills.

The architecture ensures that the “sealed” integrity of the instrument is not compromised during this scrutiny. Instead of verifying the contents, the witnesses and the notary verify the testator’s intent and the integrity of the CID. As delineated in Figure 8, the notarization workflow is structured as a sequence of cryptographically bound attestations:

1. Witness Attestation and Consensus

The designated witnesses are required to provide digital signatures that correspond to the specific CID recorded in Phase 1. This act functions as a distributed affidavit; by signing, witnesses attest that the digital envelope was indeed presented by the testator and remains untampered with since its upload. This prevents “document swapping” attacks where a malicious actor might attempt to notarize a fraudulent CID.

2. Notarial Authentication and Finality

Upon receiving the requisite witness signatures, the notary invokes the notarizeCid() function within the WillFactory contract. This operation acts as the final “seal” on the digital instrument. The contract logic enforces an asymmetric authority constraint: the notary cannot proceed without the verified threshold of witness signatures, thereby programmatically mirroring the collective presence required in a physical notary’s office.

3. Transition to the Immutable State

Once the multi-signature process is finalized, the status of the CID on the blockchain transitions from “Pending” to “Notarized”. This state change is irreversible. This digital “sealing” transcends mere data entry; it anchors the instrument in a state of irreversible legal–technical formalization, effectively bridging the gap between a private draft and a probate-ready document. Unlike traditional paper-based systems—notoriously prone to custodial negligence or the physical loss of records—zkWill utilizes the blockchain as an adversarial-resistant ledger. By doing so, the protocol mitigates the persistent risk of notarial repudiation. This transition ensures that the audit trail is not merely “immutable” in a technical sense but remains judicially robust under the weight of cryptographic proof, providing a level of certainty that standard centralized databases fail to guarantee in a court of law.

Phase 3: Probate—The Oracle-Mediated Mortality Trigger

The transition from a dormant notarized record to an executable instrument represents the most critical security bottleneck in decentralized inheritance. To neutralize the risk of premature asset dissipation—whether through executor–beneficiary collusion or malicious intent—the WillFactory contract enforces a rigorous operational sequence. Specifically, the createWill() function remains cryptographically locked until a formal, verifiable proof of death is anchored to the blockchain.

Figure 9 illustrates the probate phase, where the zkWill protocol activates a notarized will through a secure, oracle-mediated verification of the testator’s death. This stage represents a critical control point, ensuring that asset distribution cannot be triggered prematurely or manipulated by malicious actors.

The Oracle as a Socio-Technical Bridge

The “proof-of-death” is not merely a data point but a legal determination fraught with jurisdictional nuances. While a granular legal analysis of death certification lies outside this technical scope, the zkWill architecture acknowledges this complexity by delegating the verification to an Oracle. This entity functions as the essential bridge between off-chain civil registries and on-chain state transitions.

In our framework, as depicted in Figure 10, this oracle may manifest as a specialized smart contract or a permissioned Externally Owned Account (EOA). The system treats the oracle as a trusted sentinel, whose sole responsibility is to validate external legal events and authorize the “Probated” state transition.

Procedural Enforcement and State Finality

Rather than a simple linear checklist, the execution workflow is an interlocking state machine:

Verifiable Confirmation: The process begins not with a trigger, but with an evidentiary audit. The oracle must verify the authenticity of the death certificate or government-issued notification before any on-chain action is taken.

Irreversible State Transition (probateWill): Only upon successful verification does the oracle invoke the probateWill() function. This act transitions the digital will’s status to “Probated”—a state change that is globally visible yet immutable.

The Activation Gateway: Crucially, the createWill() function is dormant by design; its accessibility is strictly contingent upon this prior state transition. Only after the oracle has “unlocked” the probate status can the executor initiate the deployment of the Will.sol contract and proceed with asset distribution.

This tiered authorization model ensures that the testator’s assets remain under sovereign control until the exact moment the legal criteria for succession are satisfied, effectively eliminating the “living executor” vulnerability.

Phase 4: Execution—Deterministic Asset Distribution and Executor Disintermediation

The final phase is triggered only when the testator’s legal demise is anchored on chain, transitioning the protocol from a state of preservation to one of active enforcement. The executor initiates the process by retrieving the ciphertext from IPFS via its unique CID. Crucially, the decryption occurs within a local, off-chain environment using the pre-established shared secret; this ensures that the plaintext—the most sensitive component of the estate—is never exposed to the public mempool before the execution logic is finalized.

Figure 11 illustrates the execution phase, where the zkWill protocol transitions from passive state preservation to active enforcement of the testator’s final intentions. This phase is triggered only after the testator’s death has been formally verified and anchored on chain, unlocking the conditions required for execution.

1. The Verification Paradox: ZKP as an Integrity Anchor

To prevent the executor from altering the will’s parameters during the transition from ciphertext to contract, the createWill() function mandates a Phase 2 Zero-Knowledge Proof (ZKP). This proof resolves a fundamental trust issue: it mathematically guarantees that the submitted plaintext is the faithful and untampered result of decrypting the CID-linked ciphertext.

Hash Link Integrity: The ZKP ensures the encrypted blob matches the on-chain CID perfectly.

Authentic Decryption: It verifies that the plaintext instructions presented to the blockchain are exactly what the testator sealed, effectively stripping the executor of any discretionary power to modify transfer amounts or beneficiary addresses.

2. Programmatic Finality via Smart Contract Metamorphosis

Once the ZKP is verified, the WillFactory performs a “metamorphosis,” transforming the static plaintext into a bespoke, immutable smart contract (Will.sol). Unlike traditional executors who might exercise personal judgment—or succumb to external pressure—this contract hardcodes the testator’s mandates (token quanta and recipient identities) directly into its bytecode at deployment.

The transfer of assets is subsequently governed by a tripartite security logic:

Restricted Agency: The signatureTransferToBeneficiaries() function is hardcoded with strict Access Control, accessible solely to the designated executor.

Cryptographic Authorization: The executor cannot simply “send” funds; they must provide the specific Permit2 signature generated by the testator in Phase 1.

Atomic Execution: The Permit2.sol contract acts as the ultimate arbiter, executing the permitTransferFrom() call only if the signature, the deadline, and the transfer rules align with the pre-defined on-chain state.

3. Security Analysis: The “Automated Relay” Model

As reflected in the executor’s interface (Figure 12), the zkWill architecture enforces a radical Least Privilege model. By the time Phase 4 commences, the executor is reduced to a “technical relay”—an entity responsible for initiating transactions and subsidizing gas fees, yet possessing zero technical capability to deviate from the original intent. Even in a scenario where the executor’s environment is compromised, the attacker finds no “write” access to the will’s logic; they are bound by the immutable parameters of the Will.sol contract and the cryptographic constraints of the Permit2 signature. This design achieves a rare equilibrium: the flexibility of off-chain drafting combined with the absolute, trustless finality of on-chain execution.

4.3. ZKP Implementation: A Comparative Analysis of Functional Circuits

Throughout the zkWill lifecycle, Zero-Knowledge Proofs (ZKPs) function as the primary cryptographic glue, anchored at Phase 1 (CID Upload) and Phase 4 (Will Creation). While both phases rely on SNARK-based verification, they fulfill fundamentally divergent roles: Phase 1 is a preventative gatekeeper of privacy, whereas Phase 4 is a validation engine for execution integrity.

Functional Objectives: Privacy vs. Scalability

The Phase 1 ZKP is architected to solve the paradox of “verifiable secrecy.” It allows the testator to provide a mathematical guarantee that the IPFS-stored ciphertext encapsulates a valid, signed authorization. Crucially, this proof is generated without leaking granular asset distributions or beneficiary identities to the public mempool—effectively shielding the testator’s financial privacy pre-mortem.

Conversely, the Phase 4 ZKP is driven by the pragmatic constraints of on-chain scalability. Executing complex decryption logic and iterative data validation directly within the Ethereum Virtual Machine (EVM) is not only gas-prohibitive but technically inefficient. By shifting the decryption verification off chain and presenting only a succinct validity proof to the WillFactory, the system ensures that the contract’s “metamorphosis” remains economically feasible even for large-scale digital estates.

Structural Composition and Circuit Complexity

The computational burden is non-uniformly distributed across these phases, reflecting their differing structural requirements:

Phase 1: The Composite Circuit. This is the more sophisticated of the two, necessitating an integrated circuit that performs two distinct cryptographic operations. First, it must execute Decryption Verification, proving the ciphertext-plaintext correspondence under a specific shared secret. Second, it integrates Permit Validation, verifying that the resulting plaintext adheres to the ERC-2612/Permit2 signature standard. This dual verification ensures that the will is not only authentic but programmatically “prime” for execution.

Phase 4: The Focused Decryption Circuit. In contrast, the second ZKP focuses exclusively on the decryption component. To maintain architectural cohesion and minimize the executor’s proof generation overhead, we utilize a modular subset of the Phase 1 circuit. This reuse ensures that the executor can prove the fidelity of the plaintext without needing to re-verify the signature logic already notarized in Phase 2.

Security Implications of Circuit Decoupling

By decoupling these circuits, zkWill mitigates the risk of malicious plaintext substitution. Since the Phase 4 proof must correspond to the hash anchored during Phase 1, the executor is mathematically barred from “hallucinating” a new version of the will during the decryption process. This hierarchical ZKP structure ensures that while the executor facilitates the transfer, they remain a “zero-trust” entity in the cryptographic sense.

The distinct properties and technical specifications of these two proofs are summarized in

Table 3. Comparison of ZKPs.

ZKP	Prover	Public Input	Goal	Structure
Phase 1	testator	IV, ciphertext	privacy	decryption and permit verification
Phase 4	executor	plaintext (testator, estates, salt), IV, ciphertext	scalability	decryption only

below.

4.4. Summary of Core Authorization Logic

The security architecture of zkWill is underpinned by a synergistic integration of state machine governance, cryptographic proofs, and modern authorization standards. This multi-layered approach ensures that the transition from a private intent to an executed legacy is both programmatically certain and legally robust. The specific functional components and their respective authorization constraints are detailed in

Table 4. Summary of Core Authorization Logic.

Function	Description	Permitted Roles
uploadCid	Upload IPFS CID, ZKP, and encrypted will. Pre-set two witness addresses.	Testator
notarizeCid	Submit the digital signatures of two witnesses to legally notarize a specific CID.	Designated witnesses
probateCid	Trigger the probate procedure, usually performed by designated nodes once the death of the testator has been verified.	Oracle or authorized address
createWill	After passing all verifications, an independent Will execution contract entity is officially deployed on chain.	Testator
getCidStatus	Query the status of a specific CID (e.g., uploaded, notarized, or probated) and its corresponding timestamp.	Anyone (Public)

.

1. Formalized State Machine Governance

The protocol enforces a Strict Sequential State Machine to govern the lifecycle of the testamentary instrument. By hardcoding state transitions within the smart contract logic, zkWill ensures that business processes are irreversible and immune to out-of-order execution.

Initialization (Testator Upload): The lifecycle is anchored only when the testator provides both the encrypted payload and the initial ZKP.

Validation (Witness Notarization): A multi-signature threshold must be met to “seal” the instrument, transitioning it from a draft to a formalized record.

Probate (Oracle Certification): The state machine remains “locked” until an external, verifiable condition (proof-of-death) is injected by the oracle, acting as the final gatekeeper for execution.

2. ZKP-Enhanced Privacy Equilibrium

The integration of Zero-Knowledge Proofs (ZKPs) during the uploadCid and createWill phases resolves the tension between on-chain transparency and off-chain confidentiality. The ZKP acts as a “cryptographic attestation” that the will adheres to all structural and regulatory mandates (e.g., valid signatures, token ownership) without exposing the sensitive plaintext to the public ledger. This equilibrium ensures that while the blockchain verifies the validity of the will, it never learns its content.

3. Permit2-Centric Asset Sovereignty

For the final asset distribution, zkWill leverages the Permit2 protocol to move beyond legacy “allowance” models. This mechanism achieves a high degree of “Asset Sovereignty” through two primary vectors:

Anti-Replay Protection: Unique nonces and expiration deadlines are baked into each signature, ensuring that each inheritance instruction is a “one-time” event, effectively neutralizing replay attacks.

Conditional Authorization: Unlike standard approvals, these signatures are programmatically bound to the sequential integrity of the state machine. An asset transfer is physically impossible until the contract status reaches the “Probated” phase, providing a failsafe against premature execution.

4.5. WillFactory Contract

The WillFactory serves as the core architectural layer, responsible for the global management of the entire will lifecycle:

Upload -> Notarize -> Certify -> Deploy

This contract acts not only as the generator for will instances but also as the central hub for authorization verification, ensuring that every deployed will entity strictly adheres to the established security framework.

The specific functional capabilities and the associated access control logic of the WillFactory are detailed in

Table 5. WillFactory Contract.

Function	Description	Permitted Roles
signatureTransferToBeneficiaries	Utilize the Permit2 signing mechanism (including nonce and deadline) to transfer assets from the contract to the beneficiaries.	Executor of the will

.

4.6. ZKP Circuit Performance Analysis Report

When developing ZKP circuits (such as Circom), these values represent the computational complexity and cost. A higher number of constraints directly correlates to longer proof generation times and higher hardware resource requirements.

Table 6. Mapping of User Roles to Smart Contract Functions.

Module	Technical Focus	Constraints of Key Data
AES-CTR/GCM	Used to encrypt will contents. GCM provides authentication and encryption (AEAD).	AES-256 block encryption requires approximately 119,936 constraints (gates).
Keccak256	Ethereum’s standard hash function is used to calculate the CID and address.	The computational cost for processing messages between 1 and 1086 bits is roughly 115,200 gates.
ECDSA	Verify the signatures of witnesses or testators.	The public key recovery operation within the circuit incurs a computational cost of approximately 1,509,415 R1CS constraints.
Secp256k1	Ethereum uses elliptic curve operations.	The implementation of elliptic curve scalar multiplication (ScalarMult) necessitates approximately 1,399,441 R1CS constraints.

outlines the functional mapping between user roles and smart contract operations.

1. Cryptography & Security Core

This section is critical for ensuring the privacy of the will and covers AES symmetric encryption and Keccak hashing.

2. Business Logic Execution

These circuit costs are directly related to the logic within the WillFactory code.

CID Upload Phase (cidUpload):

• 237-byte Ciphertext Processing: Approx. 4,007,789 constraints.
• Description: When uploadCid is called, the underlying ZK circuit verifies the validity of this ciphertext. This is currently the most computationally intensive stage.
• Will Deployment Phase (willCreation):
• 237-byte Ciphertext Processing: Approx. 1,805,190 constraints.
• Description: Corresponds to the createWill function. The complexity is lower than the upload phase, likely because it only needs to verify a subset of data or specific state transitions.
• Asset Transfer Authorization (permitVerify):Permit2 Signature Verification: Approx. 2,202,599 constraints.
• Description: Ensures that the authorization logic is valid within the ZK proof when assets are transferred to beneficiaries.

3. Low-Level Utilities

These are the foundational components used to build complex circuits:

• Base64 Decoding: Handles string conversions; 360-byte decoding requires 53,289 constraints.
• UTF-8 Encoding: Ensures the integrity of the text content within the will; 15-character encoding requires 15,198 constraints.
• Bitwise Operations: Includes XOR, Shifts, etc. These typically have minimal overhead (24 to 576 constraints).

4. Data Observations & Conclusions

• Performance Bottlenecks: The heaviest computations are concentrated in ECDSA signature verification and large-scale ciphertext processing (cidU-pload). This explains why ZKP systems generally require high-performance client-side hardware for proof generation.
• Permit2 Overhead: The cost of verifying a Permit authorization involving two assets (Estates)—with approximately 2.3 M constraints—is significantly higher than that of simple hashing. This is due to the complex elliptic curve pairings and point multiplications required within the circuit.

5. System Implementation and Engineering Methodology

5.1. Tech-Stack Synergy and Architectural Integration

The implementation of our proposed framework manifests as a cohesive multi-tier architecture, systematically partitioned to balance decentralized integrity with frontend accessibility.

Table 7. Summary of Technical Stack.

Component	Technology
Frontend	React, Vite, TypeScript, ethers.js, Helia
Backend	Express, TypeScript
Smart Contracts	Solidity (Foundry, OpenZeppelin)
ZK Proofs	Circom, snarkjs, circom_tester

elucidates the core technological choices, ranging from reactive interface components to cryptographic primitives.

The frontend layer leverages ethers.js as the primary conduit to the Ethereum Virtual Machine (EVM), while Helia is integrated to provide the necessary IPFS abstraction for decentralized content addressing. To ensure the robustness of the contract layer, we utilized the Foundry (version 1.0.0) suite for invariant testing and gas profiling, alongside OpenZeppelin’s (version 5.6.1) audited libraries. The cryptographic backbone, defined through Circom, translates high-level logic into R1CS constraints, with snarkjs facilitating the generation and verification of proofs.

5.2. Evolutionary Authorization: Beyond the Constraints of ERC-20

5.2.1. Mitigating Impedance Mismatch via Uniswap Permit2

In Phase 1 of our implementation, we transition from the antiquated, two-step approve() workflow to the more efficient permit() mechanism dictated by ERC-2612 [12]. However, a fragmentation issue persists: many legacy ERC-20 tokens lack native EIP-2612 support. To bridge this gap, our system incorporates the Uniswap Permit2 module [34] as a cryptographic intermediary.

Permit2 functions as a secondary administrative abstraction layer. By granting a singular, high-allowance authorization to the Permit2 contract, users can retrospectively execute signature-based approvals—even for non-native tokens. Our implementation specifically tailors the Permit2 data structure to meet the unique requirements of digital inheritance:

• The Longevity Constraint (Deadline): Unlike standard DeFi transactions, a will requires extreme temporal validity. We default the deadline to 100 years, ensuring that the authorization remains actionable across the testator’s remaining lifespan.
• Entropy and Integrity (Nonce): To fortify the system against replay vectors, a 16-byte cryptographically secure nonce is generated locally, ensuring the uniqueness of each authorization event.
• The Spender Dependency: A critical architectural paradox arises here: the Spender must point to the Will contract, yet this contract is not instantiated until the testator’s demise in Phase 4. We resolve this temporal deadlock through the deterministic capabilities of the CREATE2 opcode.

5.2.2. Pre-Calculating the Future: Deterministic Orchestration via CREATE2

The CREATE2 opcode EIP-1014 [35] is fundamental to our system’s ability to “pre-authorize” a non-existent entity. While the conventional CREATE opcode yields addresses contingent on the deployer’s volatile nonce—making long-term prediction impractical—CREATE2 derives the contract address from a static set of parameters:

address = keccak256(0xFF + sender + salt + keccak256(init_code)) [12]:

By stabilizing these variables within the zkWill framework, the address of a future Will contract becomes entirely predictable:

• Sender: Permanently bound to the immutable WillFactory address.
• Salt: A 32-byte entropy source, generated during Phase 1 and preserved within the encrypted state.
• Init_code: Synthesized from the Will bytecode and metadata-derived constructor parameters.

To operationalize this, the WillFactory exposes a predictWill() view function. This architectural choice is strategic: by calculating the address off chain as a view-only operation, testators can finalize their pre-authorizations in Phase 1 without emitting on-chain events that might compromise privacy. In Phase 4, the executor simply provides the original parameters to the factory, which redeploys the contract to the exact address calculated years—or even decades—prior. This mechanism effectively bridges the gap between current intent and future execution without necessitating an active on-chain presence during the interim.

5.3. Cryptographic Primitives and ZK Optimization

To uphold the dual imperatives of data confidentiality and on-chain integrity, the system integrates a robust suite of cryptographic primitives. We employ AES-CTR for symmetric encryption of will contents, while leveraging Keccak256 for hashing and ECDSA for digital signatures. This selection ensures seamless alignment with the Ethereum Virtual Machine (EVM) environment.

5.3.1. Design Trade-Offs: The Case for AES-CTR over GCM

A critical architectural decision involved evaluating AES-GCM (Galois/Counter Mode) against the standard CTR mode within the context of Circom-based ZK-circuits. While GCM provides built-in authentication via the authTag, our experimental benchmarks (

Table 8. AES Circuit Comparison: GCM vs. CTR.

Metric	CTR Mode	GCM Mode	Difference
Base overhead	~86 k	~190 k	+104 k (GHASH setup)
Per block (AES-128)	~87 k	~104 k	+17 k (GHASH per block)
Scalability	Linear O(n)	Linear O(n)	GCM has higher constant
AAD cost	N/A	~17 k/block	Auth overhead
Non-std IV penalty	N/A	+34 k	GHASH IV processing

) reveal a prohibitive computational premium:

▪

Overhead Analysis: GCM introduces a ~104 k constraint penalty for GHASH initialization and an additional 20% per-block cost.

▪

Redundancy of Authentication: In our pipeline, once the ciphertext is committed to IPFS, its immutability is guaranteed. While GCM’s authTag can detect pre-upload tampering, it cannot recover the original data post-demise. More importantly, the Phase 1 ZKP inherently validates the plaintext’s schema and the Permit2 signature; any tampering that violates these constraints would result in a proof generation failure.

Consequently, we opted for AES-CTR, as the ZKP layer effectively renders GCM’s authentication redundant while significantly lowering the proving burden.

5.3.2. ECDSA ZKP Verification

We approach Zero-Knowledge Proofs (ZKPs) for ECDSA signatures from two perspectives:

• Signature Generation ZKP: The prover provides a private key and a message hash to ensure the signature is correctly generated. The resulting signature is guaranteed to pass verification.
• Signature Verification ZKP: The prover provides a message hash, a signature, and a public key, and the circuit directly verifies their validity.

0xPARC provides a Circom implementation of the ECDSA [36] that adopts the second approach. Specifically, the ECDSAVerifyNoPubkeyCheck() circuit validates the public key, while PubkeyToAddress() converts a public key to an Ethereum address. Both circuits are optimized for efficiency.

Building on this foundation, we implement the ECDSA signature verification circuit as follows:

Inputs: message hash, signature, target address.

• Decode the signature into (r,s,v) and convert v into the recovery ID (0 or 1).
• Recover the public key using unconstrained functions in Circom.
• Verify the recovered public key with ECDSAVerifyNoPubkeyCheck(r,s,msgHash,pubkey).
• Convert the public key to the Ethereum address (signer) using FlattenPubkey() and PubkeyToAddress().
• Ensure that the signer matches the target address.

Although public key recovery (step 2) is typically performed in a conventional programming environment, our system initially encrypts both the message hash and the signature, making direct recovery impossible. Performing public key recovery within Circom using unconstrained functions increases compilation costs but does not affect proof generation or verification costs, which is critical for maintaining a smooth user experience.

Table 9. ECDSA-related circuit size.

Circuit Name	Circuit Size (#Constraints)
ECDSAVerifyNoPubkeyCheck	1,508,904
FlattenPubkey	512
PubkeyToAddress	115,200

summarizes the circuit sizes for ECDSA-related operations.

5.3.3. Structural Optimization of Keccak256 ZK-Circuits

The Keccak256 component within the 0xPARC ECDSA framework traditionally relies on the keccak256-circom experimental implementation by Vocdoni [37]. However, empirical profiling reveals significant scalability bottlenecks in this baseline: even a marginal 1-bit input necessitates approximately 138,170 constraints, with the complexity escalating non-linearly alongside message length. More critically, the Vocdoni circuit exhibits a failure to converge for payloads exceeding the primary 1088-bit block, rendering it incompatible with the high-entropy datasets characteristic of complex wills.

To circumvent these constraints, we engineered a high-performance Keccak256 variant tailored for arithmetic circuit efficiency. As demonstrated by the comparative metrics in Figure 13 and

Table 10. Keccak256 circuit size comparison (raw data).

#Message Bit	1	256	512	1080	1086	1087	1088	1360
Vocdoni’s Version	138,170	150,848	151,424	152,560	×	×	×	×
Our Version	115,200	115,200	115,200	115,200	115,200	230,400	230,400	230,672

, our implementation introduces three transformative advantages:

• Asymptotic Efficiency and Constant-Cost Baseline: For all message lengths, our circuit maintains a consistently smaller footprint than the baseline, achieving a peak reduction of 24.5%. Crucially, within the bounds of a single permutation block, our implementation exhibits a constant constraint cost, whereas the Vocdoni version demonstrates an inefficient “creep” in complexity as bits are added.
• Decoupled Padding Logic: The stability of our constraint count stems from an optimized padding orchestrator that decouples input injection from the core permutation rounds. This prevents the redundant generation of intermediate constraints that typically plague unoptimized R1CS (Rank-1 Constraint System) representations of Keccak.
• Arbitrary Payload Scalability: By implementing a modular “step-function” scaling model, our circuit effectively supports messages of arbitrary length. While the 1088-bit threshold triggers a discrete jump in constraints (reflecting the initiation of a second permutation cycle), the circuit remains functional and efficient, bridging the gap where the baseline implementation (marked as x) collapses due to architectural limitations.

As delineated in Figure 13, the comparative analysis of Keccak256 implementations reveals a striking contrast in their underlying constraint architectures. Our optimized version introduces a deterministic step-function scaling model, which offers a significant performance advantage over the conventional Vocdoni implementation across disparate message lengths.

5.4. Circom Testing Framework

To ensure that Circom circuits generate correct witnesses, we perform both unit testing and integration testing. We adopt the circom_tester library [38], which provides a JavaScript/TypeScript-based framework for compiling and testing Circom circuits locally. Building upon this foundation, Circomkit [39] further automates and modularizes the compilation and testing workflow.

However, these open-source tools do not yet support several features introduced in Circom 2, including tags and bus types, and they still contain unresolved implementation bugs. To overcome these limitations, we developed a new Circom testing framework that follows the design philosophy of circomkit while extending the functionality of circom_tester to enable fully automated circuit testing under Circom 2.

The proposed framework provides the following enhancements:

• Debugging:The framework resolves multiple issues in circom_tester, including failures when reading .sym files larger than several gigabytes [40] and issues with the release() function.
• Untagging: Circom 2.1 introduces tags to improve the readability of input and output signals or buses within components. However, when tags appear in the input signals or buses of the main component, compilation fails. To address this issue, we implement an automated untagging function that generates tag-free input templates. This function supports both signal and bus input types, ensuring that automated testing executes smoothly.
• Bus Type Support: Circom 2.2 introduces bus types, which group related signals into structured collections analogous to C/C++ structs. Bus types improve code organization and readability. Following the architectural style of Circomkit, our framework extends existing signal-type support to fully incorporate bus types.
• Benchmarking: The framework records the number of constraints generated by each circuit and further categorizes them according to template parameter settings. For each unique parameter combination, the framework stores a separate count of constraints in a JSON file for subsequent analysis. It automatically updates benchmark data after each test execution.

5.5. Circuit Compilation and Contract Deployment

The operational integrity of the proposed system hinges upon the strategic pre-deployment of four specialized smart contracts. At the architectural core lies the WillFactory—the primary orchestrator facilitating cross-entity interactions—complemented by the JsonCidVerifier for cryptographic URI validation and two distinct zk-SNARK verifiers tailored for Phase 1 and Phase 4 proofs. The synthesis of these verifiers necessitates an upstream compilation of Circom circuits, where high-level arithmetic constraints are transcribed into Solidity-based verification logic.

5.5.1. The Criticality of Trusted Setup in Groth16

Given our architectural reliance on the Groth16 protocol [41], a multi-stage trusted setup is non-negotiable. This procedure, split between a universal “Powers of Tau” (pTau) phase and a circuit-specific ceremony, yields the immutable proving and verifying keys.

Note: Rather than generating pTau parameters de novo, we leverage the Privacy and Scaling Explorations (PSE) repository [42], ensuring that our selection adheres to the logarithmic constraint: $2^n \geqq \mathrm{T}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}$ Constraints. This selection is not merely a preference but a prerequisite for maintaining the soundness of the zero-knowledge argument.

5.5.2. Constraint Optimization and Serialization Bottlenecks

Systemic latency—specifically proving time—is fundamentally tethered to the constraint density, which in our implementation is a direct function of the sealed will’s payload. To circumvent excessive computational overhead, we adopt an aggressive serialization strategy:

• Field Omission: All non-essential metadata and field names are stripped during serialization to compress the witness size.
• Estate Scalability: While Phase 1 (IPFS ingestion) and Phase 4 (decryption/deserialization) are inherently complex, the current iteration caps estate support at two instances to maintain a manageable cryptographic footprint.

Under these parameters, the system demands a pTau file of step size $2^{23}$ (approx. 9.66 GB). Detailed empirical benchmarks regarding these constraints are further dissected in Section 6.

5.5.3. Overcoming EIP-170 Limits: The Split-Verifier Approach

A significant technical hurdle emerged during deployment: the Circom-generated verifiers inherently exceeded the 24,576-byte limit mandated by EIP-170 [43]. To bypass this protocol-level ceiling, we implemented a modularization strategy, decoupling the large constant data arrays into independent auxiliary contracts.

As evidenced by the post-optimization metrics for the CidUploadVerifier (Phase 1) and WillCreationVerifier (Phase 4) in Figure 10 and Figure 11, this bifurcation successfully brought the bytecode within deployable bounds. It is worth noting, however, that such structural modifications to a verifier’s bytecode could theoretically compromise the proof’s validity. To mitigate this risk and ensure auditability, we have open-sourced the transformation scripts, allowing for independent verification of the contract’s functional parity with the original Circom output.

6. Evaluations

6.1. Hardware Configuration and Network Environment

Empirical evaluations were executed on a workstation featuring the Apple M4 Pro architecture (14-core CPU), integrated with 48 GB of unified memory and operating under macOS Tahoe 26.0.1. This high-bandwidth memory architecture was specifically leveraged to mitigate I/O bottlenecks during large-scale circuit synthesis. To simulate real-world decentralized conditions, all smart contract logic was deployed on the Arbitrum Sepolia testnet. Detailed contract addresses and their respective deployment parameters are systematically cataloged in

Table 11. Contract addresses on Arbitrum Sepolia.

Contract Name	Address	Description
JsonCidVerifier.sol	0×7ebf5323158e7693de9a8721917d9fd9a02086c3	for CID verification
CidUploadVerifier.sol	0x397bc59d8a80f5d12d48b84834f3f41f150fff6f	for Phase 1 ZKP verification
WillCreationVerifier.sol	0xb98b1a71d97aed3788a8d390e9ab85e7134464	for Phase 4 ZKP verification
WillFactory.sol	0x11aa4c456030014760beb7ba94e66a90a23d3ca	main contract
Will.sol	0xd4f6fa02dfecac09c07c10e96f136369a8bad22d	deployed by WillFactory

6.2. Circuit Complexity and Constraint Analysis

The computational overhead of the proposed ZK circuits, specifically the relationship between circuit size and the Powers-of-Tau (pTau) setup requirements for Phase 1 and Phase 4, is summarized in

Table 12. Circuit size vs. different number of estates.

Phase	#Estates	Ciphertext		n = Number of Constraints			pTau Size
		(Bytes)	(Blocks)	(n)	Δn	log2(n)
Phase 1	1	237	15	4,007,789	–	21.934	222
	2	293	19	4,604,721	596,932	22.135	223
	3	349	22	5,081,684	476,963	22.277	223
	4	405	26	5,678,616	596,932	22.437	223
	5	461	29	6,270,971	592,355	22.58	223
	6	517	33	6,868,159	597,188	22.711	223
	7	573	36	7,345,378	477,219	22.808	223
	8	629	40	7,942,566	597,188	22.921	223
Phase 4	1	237	15	1,805,190	–	20.784	221
	2	293	19	2,286,410	481,220	21.125	222
	3	349	22	2,647,661	361,251	21.336	222
	4	405	26	3,128,881	481,220	21.577	222
	5	461	29	3,490,132	361,251	21.735	222
	6	517	33	3,971,352	481,220	21.991	222
	7	573	36	4,332,603	361,251	22.047	223
	8	629	40	4,813,823	481,220	22.199	223

. Our analysis assumes a configuration supporting up to eight estates. A critical observation emerges regarding the scalability of constraints: while the number of constraints remains deterministic for fixed template parameters, it is sensitive to the ciphertext’s byte structure. Specifically, each incremental estate introduces a 56-byte overhead to the ciphertext. Although this necessitates additional cryptographic operations, the resulting growth in constraint count exhibits a quasi-linear trajectory rather than a strictly proportional one, reflecting the non-trivial costs of padding and boundary management in arithmetic circuits. In Phase 4, the constraint expansion follows a predictable, modular pattern dictated by the 16-byte block size of the underlying AES primitive. We calculated that each additional AES block adds approximately 120 k constraints, a figure that underscores the trade-offs between symmetric cipher integration and circuit efficiency.

Comparative Functional Efficiency

The divergence in complexity between Phase 1 and Phase 4 is largely functional. Phase 4 serves as a functional subset, deliberately omitting the most computationally expensive primitives—namely Keccak-256 hashing and ECDSA signature verification—which are central to the Phase 1 integrity checks. By offloading these components, Phase 4 achieves a reduction in constraint volume of over 50%, significantly lowering the bar for prover performance.

Setup Requirements

From a system-wide perspective, the required pTau file size depends on the Phase 1 circuit. A $2^{22}$ sized pTau file is sufficient when supporting a single estate, while systems handling two to eight estates should use a $2^{23}$-sized file. To accommodate more estates, a pTau file of at least $2^{24}$ is estimated to be necessary.

6.3. Temporal Performance and Computational Latency

The computational latency across distinct processing stages—configured for single and dual-estate scenarios—is detailed in

Table 13. ZKP time consumption for each stage.

ZKP	#Estates	Setup Time		Proof Gen		Verification (Off-Chain)
		Compilation	Trusted Setup	Witness Generation	Proving
Phase 1	1	2:31.2	25:45.8	3:14.5	57.311	0.21
	2	2:52.5	30:43.6	3:15.5	1:18.5	0.213
Phase 4	1	57.438	8:34.8	7.407	19.359	0.211
	2	1:16.0	12:13.4	9.539	32.677	0.212

. While the compilation and trusted setup phases represent significant temporal investments, it is imperative to distinguish these as one-time developer-side overheads that remain transparent to the end-user. Our data indicate that the trusted setup remains the most time-intensive operation, exhibiting a direct linear correlation with the expansion of circuit constraints.

User-Centric Latency Analysis

From a pragmatic deployment perspective, the system’s viability hinges on the Total Proof Generation Time, a composite metric of witness generation and the cryptographic proving process. Empirical results reveal a stark contrast between phases:

• Phase 1 (Comprehensive Verification): Requires a substantial commitment of over four minutes per estate.
• Phase 4 (Optimized Subset): Operates with significantly higher efficiency, concluding in under thirty seconds.

Complexity and Scalability Projections

The observed performance profiles are deeply rooted in the underlying Groth16 zk-SNARK protocol [41]. Theoretically, witness generation scales linearly, denoted as O(n), whereas the proving stage adheres to a quasi-linear complexity of O(n log n), where n represents the circuit size.

• Critical Insight: This complexity divergence suggests that while Phase 1 provides robust verification, it imposes a heavier “prover’s tax”. Based on our incremental scaling analysis, we estimate that each additional estate introduces a latency penalty of approximately 20–30 s for Phase 1, compared to a more manageable 10–20 s for Phase 4. This scalability profile underscores a deliberate architectural trade-off: Phase 1 prioritizes cryptographic rigor, while Phase 4 optimizes for the responsive throughput required in high-frequency user interactions.

6.4. Gas Expenditure and On-Chain Economic Efficiency

As synthesized in Table 9, while off-chain verification latency for both circuits remains sub-second, such wall-clock metrics are secondary in decentralized deployments. The true bottleneck in production environments is the on-chain verification overhead, where block confirmation finality is governed by network congestion and consensus constraints rather than raw execution speed. Consequently, we quantify the system’s operational cost through gas consumption, providing a more deterministic benchmark across varying blockchain environments.

Transactional Cost Dynamics

Table 14. Cost for each transaction on Arbitrum Sepolia.

Test Date	Upload CID	Notarize CID	Probate CID	Create Will	Transfer Assets
3 November 2025	0.000580507/2.11	0.0000065854/0.02	0.0000049572/0.02	0.0006521564/2.37	0.000013864/0.05
4 November 2025	0.0005838179/2.04	0.0000065881/0.02	0.0000049594/0.02	0.0006554655/2.27	0.000013864/0.05
6 November 2025	0.0005796208/1.93	0.0000065881/0.02	0.0000049594/0.02	0.0006512688/2.17	0.000013864/0.05

Note: All costs are shown in ETH/USD, recorded based on on-chain data from Arbitrum Sepolia at the time of each transaction. The ETH price during testing ranged approximately between 3300 and 3800 USD.

delineates the specific transaction fees associated with each core system interaction on the Arbitrum Sepolia network. Given the inherent volatility of ETH valuations and fluctuating base fees, our analysis prioritizes relative gas utilization over absolute fiat-equivalent costs. A primary observation is the significant gas premium associated with the uploadCid() and createWill() functions. This expenditure is fundamentally attributed to the computational intensity of verifying Zero-Knowledge Proofs (ZKPs) directly on the EVM (Ethereum Virtual Machine).

Constant-Time Verification and Scalability

A critical technical takeaway from our evaluation is the verification cost invariance. Despite the underlying circuits for these transactions differing in complexity by a factor of over $2x$, the on-chain verification gas remains remarkably stable. This phenomenon is a direct consequence of the Groth16 zk-SNARK protocol architecture, where verification complexity is decoupled from circuit size. Specifically, we observed the following:

• The createWill() transaction incurs a marginal 12% gas increase compared to uploadCid().
• This variance is strictly an artifact of the Will contract deployment logic and storage initialization, rather than a reflection of proof complexity.

Technical Synthesis: This constant-time verification property is the cornerstone of our system’s scalability. By abstracting the computational burden of complex estate logic into a fixed on-chain cost, we ensure that the system remains economically viable for users, regardless of the intricacy of the underlying cryptographic claims.

6.5. Security Posture and Formal Properties

While Section 6.1, Section 6.2 and Section 6.3 provide a quantitative benchmark of resource consumption, this section qualitatively evaluates the architectural guarantees that underpin the system’s reliability. We focus on the tripartite pillars of Integrity, Privacy, and Executability, which collectively ensure that the digital will satisfies both cryptographic robustness and the stringent requirements of inheritance law.

6.5.1. Integrity and Non-Repudiation Framework

The system enforces a “defense-in-depth” approach to data integrity. At its core, the integrity of a testamentary directive is anchored by the testator’s digital signature, which is cryptographically bound to the sealed will.

Unlike traditional systems, we augment this with a Zero-Knowledge Proof (ZKP) verification layer. This layer proves that the ciphertext contains a valid Permit2 signature corresponding to a legitimate asset transfer, without decrypting the payload. By anchoring these proofs on an immutable ledger, the system inherently achieves:

Non-forgeability: Unauthorized entities cannot generate a valid ZKP–signature pair.

Non-repudiation: The sequential recording of the CID on chain provides an irrefutable audit trail, preventing the testator from later denying the intent or the content of the directive.

6.5.2. Multi-Layered Privacy Preservation

Privacy is maintained through a combination of AES-256-CTR symmetric encryption and off-chain storage abstraction. By storing only the Content Identifier (CID) on the blockchain, the system minimizes the data footprint exposed to public scrutiny.

The confidentiality of the will is guarded by a restricted key-sharing model involving only the testator and the designated executor. Crucially, the ZKP verification process facilitates “blind validation”—it confirms the structural and cryptographic validity of the will without leaking the underlying asset distribution or beneficiary identities. This aligns with the “Sealed Will Principle”, ensuring that beneficiaries remain unaware of their specific status until the probate trigger is activated, thereby mitigating potential familial or legal conflicts during the testator’s lifetime.

6.5.3. Guaranteed Executability and State Finality

Executability is not merely a functional goal but a cryptographically enforced constraint. The submission of a ZKP at the time of CID upload acts as a “proof of feasibility.” This proof guarantees that the sealed container holds a syntactically correct and authorized Permit2 signature.

This pre-validation mechanism ensures the following:

• Atomicity: The inheritance transfer logic in createWill() and signatureTransferToBeneficiaries() can only be invoked if the initial ZKP has been verified.
• Orderly Transition: It prevents the system from entering an “invalid state” where a will is recorded but cannot be executed due to malformed signatures.
• Technical Synthesis: By intertwining ZK-SNARKs with standard cryptographic primitives, the system transcends the limitations of traditional digital wills. It achieves a state where the will is integral by design, private by default, and executable by proof, fulfilling the dual mandates of technical security and legal testamentary validity.

6.6. Threat Model and Security Countermeasures

To rigorously validate the security guarantees of the proposed architecture, we analyze its resilience against potential adversarial vectors. The following table synthesizes the relationship between specific security threats and the cryptographic countermeasures implemented in our design.

Table 15. Resilience Analysis against Adversarial Threats.

Threat Category	Adversarial Objective	Mitigating Countermeasure	Security Property
Data Tampering	Unauthorized modification of the sealed will’s content on-chain.	ZKP + Immutable Hashing (IPFS CID): Any bit-level change to the ciphertext invalidates the ZKP and results in a mismatched CID.	Integrity
Impersonation	Forging a testator’s intent to redirect assets to an attacker.	ECDSA Digital Signatures: Only the holder of the testator’s private key can generate a valid Permit2 signature required for the ZKP.	Non-forgeability
Unauthorized Disclosure	Beneficiaries or third-party nodes leaking the will’s contents prematurely.	AES-256-CTR + Off-chain Sealing: The blockchain only records the CID; decryption keys are restricted to the executor and testator.	Confidentiality
Execution Sabotage	Preventing the legitimate transfer of assets during the probate phase.	ZKP Pre-validation: The system ensures the “executability” of the signature before the will is officially recorded on chain.	Liveness/Executability
Double Claiming	An executor attempting to trigger the inheritance transfer multiple times.	Smart Contract Nonces & State Machine: The contract tracks the probate status, ensuring the createWill() logic is executed atomically and only once.	Anti-replay

presents a comprehensive resilience analysis of the proposed system against a range of adversarial threats. As shown in Table 15, each identified threat category—such as data tampering, impersonation, unauthorized disclosure, execution sabotage, and double claiming—is systematically mapped to its corresponding cryptographic countermeasure, including zero-knowledge proofs (ZKP), ECDSA digital signatures, AES-256 encryption, and smart contract state control mechanisms. These countermeasures collectively ensure critical security properties, namely integrity, non-forgeability, confidentiality, liveness, and anti-replay. The analysis demonstrates that the architecture not only mitigates individual attack vectors but also provides a holistic security framework that safeguards both the correctness and the executability of on-chain inheritance processes.

7. Conclusions and Future Work

7.1. Conclusions

The management of on-chain inheritance is expected to attract increasing attention in the future. Under Taiwan’s Civil Code, only paper-based sealed wills are legally recognized. Although this approach provides strong privacy protection, it suffers from significant limitations in terms of integrity and executability. Conventional digital wills can ensure integrity and privacy to some extent; however, executability remains problematic, and improper trust assumptions may even lead to the leakage of the testator’s wallet private key.

In recent years, several blockchain-based solutions for on-chain inheritance have been proposed, each with a relatively comprehensive system architecture. Nevertheless, their operational procedures—particularly the mechanisms for determining and verifying the testator’s death—do not fully align with the legal requirements of Taiwan’s Civil Code, limiting their practical applicability in real-world legal contexts.

To address these challenges, we propose zkWill, a system whose workflow is explicitly designed to comply with the legal requirements for sealed wills stipulated in Taiwan’s Civil Code. By integrating Permit2, CREATE2, IPFS, and zero-knowledge proofs (ZKPs), zkWill simultaneously ensures integrity, privacy, and executability while eliminating the risk of wallet private key leakage. The use of ZKPs enables the system to verify the will’s executability without revealing its contents, thereby faithfully preserving the sealed will principle.

Furthermore, during system development, we implemented AES encryption in CTR and GCM modes, supporting 128-, 192-, and 256-bit keys, and designed a Keccak256 circuit with fewer constraints than the standard Keccak256-circom implementation. We also developed an automated testing framework for Circom circuits, which we released as an open, reusable tool for other developers. These contributions not only support the zkWill system but also provide practical building blocks for future research and development in zero-knowledge-based blockchain applications.

7.2. Future Work

7.2.1. Dynamic Format Support

The current Sealed Will proof circuit is implemented in Circom as a domain-specific circuit, which restricts it to predefined structures (e.g., a hard-coded upper bound of two estates). Future research could explore the integration of zero-knowledge Virtual Machines (zkVMs), such as RISC Zero [44]. This transition would enable support for dynamic data structures, such as variable-length arrays, and eliminate the need for a Trusted Setup, thereby relieving provers from the burden of downloading multi-gigabyte Powers of Tau (pTau) files. However, the primary trade-off of adopting zkVMs is an increase in constraint complexity and proof size, which may adversely affect proof efficiency and on-chain verification costs.

7.2.2. Proportional Asset Distribution

The existing implementation is limited to fixed-amount transfers (e.g., a specific number of tokens). It lacks support for the proportional allocation of residual assets, such as percentage-based distribution or fractional shares. To facilitate fractional inheritance, future iterations could incorporate a tokenization layer similar to WillChain. Utilizing mechanisms such as Refundable Tokens (RFTs) or EIP-4626 Tokenized Vaults would enable precise computation and management of entitlements relative to the total asset balance at the time of execution.

7.2.3. Enhancing Data Availability

The current system relies on IPFS to store sealed wills; however, data persistence is not guaranteed unless nodes “pin” the content. To mitigate the risk of data loss, future work could integrate IPFS with incentive-based storage networks like Filecoin or leverage dedicated Data Availability Layers (DALs) such as Celestia. These solutions provide stronger cryptographic guarantees for long-term data accessibility.

7.2.4. Cross-Chain and Asset Compatibility

Compatibility challenges remain in two primary dimensions:

Asset Compatibility: Current support is restricted to ERC-20 tokens. Expanding the framework to include Non-Fungible Tokens (NFTs) and Real-World Assets (RWAs) will require specialized circuit designs and state handling.

Chain Compatibility: The system is currently optimized for EVM-compatible blockchains. Non-EVM platforms, such as Solana or Sui, lack direct equivalents to the Permit2 module. Supporting these ecosystems would necessitate a fundamental redesign of the transaction workflow and a complete reimplementation of the underlying cryptographic circuits.

7.2.5. Executor-Side Confidentiality

In the current architecture, the designated executor holds the decryption keys, potentially granting them premature access to the will’s contents. To strengthen confidentiality, future work could explore decentralized key management. One promising direction is distributing decryption shares among multiple independent parties via Multi-Party Computation (MPC). Alternatively, Time-Lock Cryptography—such as the timed-execution scheme by Li et al. [45] or Timed Secret Sharing (TSS) by Kavousi et al. [46]—could be employed to ensure they will remain encrypted until a strictly defined timestamp.

7.2.6. Quantum Resistance and Long-Term Integrity

While the system meets current security requirements, the advent of functional quantum computing may threaten conventional primitives such as AES-256-CTR. To bolster post-quantum security, future iterations could incorporate Designated Verifier Proofs (DVPs) [47]. This approach ensures that a Zero-Knowledge Proof (ZKP) is only verifiable by a specific notary. Under this paradigm, even if an adversary compromises the underlying encryption, they would remain unable to verify the proof’s authenticity, thereby preserving the system’s long-term integrity.