Can Ownership Become a Privacy Primitive?

Index Terms: blockchain privacy, cryptographic ownership, ownership continuity, fragmentation, selective disclosure, zero-knowledge proofs

1. Introduction

Most blockchain privacy work begins with visible facts: sender, recipient, amount, balance, or identity attribute. I focus on a different leak: the relationship that tells an observer those facts belong to the same owner over time. Reused long enough, an address becomes a join key.

1.1 Contribution and Limits

The assumption I am pushing back on is small but load-bearing: a ledger must remember the same owner label after every authorized transition. I am not sure it does. I replace the account with an ownership object, distinguish ephemerality from fragmentation, and propose four constructs a prototype could test. This is an architecture and evaluation vocabulary, not a new proof system, measured anonymity result, or production-security claim. GhostShard already explores ownership fragmentation for the EVM, so I treat it as the closest related work [14].

1.2 Methodology

The method has four parts. I reviewed primary specifications for Zcash Orchard, Monero RingCT, Aleo records, Aztec notes and nullifiers, Ethereum stealth addressing, W3C Verifiable Credentials, and hardware-backed signing [4], [5], [6], [7], [8], [13], [21]. I pulled their recurring mechanisms into one protocol-neutral model, tried it against three constructed workflows, and derived the Section 5 measurements from the points where it failed.

This is a qualitative architecture study, and the scenarios are synthetic. I did not analyse millions of addresses, implement circuits, or benchmark proof generation. I have no scan times, success rates, or privacy scores to report. The one Ethereum gas value is a documented precompile component, not a benchmark of this proposal [24].

2. The Privacy Problem Is Often Continuity, Not Visibility

A 2024 survey of Ethereum pseudonymity identifies address reuse and transaction linkage as recurring weaknesses [15]. Tornado Cash analysis and recent work on shielded-UTXO DeFi arrive at the same uncomfortable conclusion from opposite starting points: hidden facts do not stop transaction patterns or public boundary crossings from weakening unlinkability [16], [17]. The point is not that every user is deanonymized. Persistence gives an analyst something stable to test.

Existing systems solve stronger problems than this paper attempts. Zcash Orchard uses commitments, nullifiers, and viewing capabilities for shielded value [4]. Monero RingCT combines stealth reception, confidential amounts, and signer ambiguity [5]. Aleo represents private state as encrypted records, while Aztec uses programmable private notes and hidden note-to-nullifier links [6], [7]. W3C Verifiable Credentials 2.0 separates issuer, holder, and verifier and supports selective disclosure [13]. I ask what happens after each mechanism succeeds: can wallets, applications, or recovery procedures still group the results around one durable owner?

2.1 Threat Model and Assumptions

I distinguish three nested observers. A public-ledger observer records commitments, nullifiers, transaction inclusion, public amounts, contract calls, and timestamps indefinitely. This is the main target. An application observer also sees information exposed to a wallet service, contract, issuer, verifier, oracle, or keeper. A network observer additionally sees traffic timing, IP-level metadata, relays, and mempool ordering. Ownership rotation alone does not defeat the latter two.

The model excludes compromised wallets, stolen roots, coerced disclosure, colluding counterparties, and exchanges matching chain activity to customer records. It assumes binding commitments, collision-resistant hashes, sound proofs, unique nullifiers, and fresh randomness. Failure has different effects: a broken commitment or proof undermines integrity, while reused randomness or a predictable nullifier restores linkability. Choosing Groth16 on BN254 would add assumptions that this protocol-neutral paper does not prescribe.

3. From Private Transactions to Private Ownership

Consider a private lending position. Even if its amount is hidden, a design may still ask the same account to update collateral, borrow, repay, and exit. An observer cannot read the position but may follow its owner-shaped outline. My core move is to let the old control point disappear.

An ownership object carries six pieces of information: the controlled state; its authorization rule, which need not be a public address; a separate viewing capability; any narrowly scoped disclosure; fresh randomness; and an expiry or replay boundary. I write it as

where:

• C commits to the asset or state being controlled;
• A is the authorization predicate and need not be a public account address;
• V is an optional viewing capability, separate from spend authority;
• D is a disclosure capability scoped to a fact, object, or interval;
• R is fresh randomness used to break continuity; and
• E is an epoch, expiry, or replay-control value.

A transition consumes one or more old objects and creates fresh objects:

where w is a private witness, π proves the application rules, and each N_j is a deterministic but hiding nullifier. The verifier checks membership, authorization, application constraints, proof validity, and nullifier uniqueness. It need not receive a permanent owner address. The lifecycle is receive, discover, consume, and renew. Aztec and Zcash demonstrate this consume-and-create pattern for private state and shielded value [7], [4]; I abstract it as a candidate ownership interface across applications.

4. Two Mechanisms: Ephemerality and Fragmentation

Ephemerality replaces an old representation after use. Shielded-note systems already do this: an old note is nullified and fresh notes are created [4], [7]. Its value is the absence of address reuse; its costs include note discovery, proof work, local state, and recovery.

Fragmentation divides one logical holding into independent objects. A monthly payment might become compartments for bills, savings, and discretionary use. Spending one should not reveal the state of the others. Fragmentation is not automatically private: too few objects preserve obvious patterns, while too many increase scanning, inputs, backups, fees, and the chance that a later merge becomes a fingerprint. The research question is the useful range, not the maximum count.

Nullifier management is where this gets practically difficult. Global uniqueness prevents double spending, so the public nullifier set, a record of used objects, is append-only in systems such as Aztec [7]. Wallets also need encrypted local records mapping notes to spend status. Pruning without an accumulator can break validation; retaining local history can expose a complete graph after device compromise. A serious design must specify public accumulation, local rescan, and recovery disclosure before claiming privacy.

5. New Evaluation Formulations

Privacy terminology distinguishes anonymity from unlinkability, while k-anonymity and differential privacy answer different questions [1], [2], [3]. k-anonymity concerns indistinguishability in released data; differential privacy bounds how an output distribution changes when one record changes. Neither tells us how many durable handles link one blockchain event to another. The four constructs below are not anonymity metrics. They are narrower comparative tools and do not replace those frameworks or security guarantees.

5.1 Ownership Continuity Exposure

For a fixed observer and pre-registered workload, let J be the set of plausible join features and I ⊆ J the features that actually support a tested link. Ownership Continuity Exposure (OCE) is

Features might include address reuse, timing, amount pattern, asset type, application identifier, and change relationship. Each needs an explicit rule plus false-positive and false-negative reporting. An OCE of 5/6 does not mean “83% identifiable.” It means five declared signals supported a join for that observer.

Table I demonstrates procedure, not performance. Its judgments are assumptions; a real study needs pre-registered rules and observed error rates.

5.2 Disclosure Reach

For a single disclosure capability d, Disclosure Reach, DR(d), is the number or weighted count of otherwise private objects or attributes that become inferable to its holder. Lower DR favors compartmentalized disclosure. A payment receipt that reveals one transfer has lower DR than a wallet-wide view key.

5.3 Fragmentation Efficiency

Fragmentation Efficiency (FE) compares the reduction in OCE with the extra system burden introduced by fragmentation. A first formulation is

where C = (b, p, s, r) is a normalized cost vector for transaction bytes, proof work, wallet scanning and storage, and recovery effort. A high value would mean that a modest increase in complexity buys a meaningful reduction in observable continuity. Weights and units must be published before comparison; the value is comparative, not absolute.

5.4 Recovery Coupling

Recovery Coupling (RC) measures how many objects are exposed or endangered by one recovery secret or event. BIP-32 can simplify deterministic backup but concentrates root-secret risk, while SLIP-39 and social recovery distribute authority without automatically hiding an on-chain recovery event [18], [19], [20]. Low RC limits correlation and loss concentration; extremely low RC can make recovery unusable.

These constructs separate cryptographic privacy from operational privacy. Hidden balances can coexist with poor OCE when a wallet, application, or recovery path exposes a durable relationship; low OCE is also useless if fragment scanning is too slow. Privacy is therefore a multi-objective engineering problem, not a single anonymity score. Of the four measures, I trust OCE least in its current form because a real adversary will not announce its join features. RC is less mature still: I can describe the exposure, but I do not yet know what a good score looks like in practice. These are starting points, not validated instruments.

6. What Existing Systems Already Teach Us

Table II is a map, not a verdict. Zcash and Monero solve stronger transaction-privacy problems than I attempt here [4], [5]; Aleo and Aztec make private state programmable [6], [7]; ERC-5564 and ERC-6538 support stealth reception and registry lookup [8], [9]; W3C VC 2.0 supports selective disclosure [13]. My question comes afterward: can a stable relationship still group the results?

Ethereum proposals need equally precise treatment. EIP-7702 permits an externally owned account to set code for delegation and batching; it is not itself a privacy protocol [10]. ERC-4337 can sponsor execution through paymasters, reducing the need for a user’s funding account to appear in one workflow, but sponsorship creates its own metadata surface [11]. EIP-4844 supplies blob-carrying transactions for data availability; it is a scaling mechanism, not a confidentiality guarantee [12].

7. Closest Related Proposal: GhostShard

Benjamin Ofem’s 2026 GhostShard proposal combines ERC-5564 stealth addressing, EIP-7702 delegation, disposable fragments, many-to-many construction, and selective disclosure [14]. Its implementation is an unaudited research prototype. I therefore cannot claim fragmentation as unexplored; GhostShard already went there. My actual contribution is smaller: a protocol-neutral ownership object that separates ephemerality from fragmentation, plus four criteria for testing whether correlation disappears or merely moves into discovery, recovery, applications, or bridges.

8. Constructed Stress Tests

8.1 Salary Income without a Public Financial Biography

Take a synthetic but realistic workflow: a DAO pays a contributor 10 units of a volatile asset each month. The contributor converts two units for bills, allocates five to savings or staking, and keeps three liquid. A persistent account exposes the monthly rhythm, conversion point, asset choices, and later protocol interactions. If a regulated exchange handles conversion, it can also connect the deposit to a legal identity.

With ownership objects, the payment creates a fresh salary object that the wallet separates into expense, savings, and opportunity compartments. Each renews only when used. A grocery payment consumes an expense object and creates fresh change; it does not require the savings object to appear. The improvement is specific: public address reuse and direct change continuity can be removed. The limits are also specific: the employer knows the payment, the exchange knows its customer, monthly timing may remain distinctive, and repeated use of one application can correlate events. I would test this with OCE rules rather than claim an unmeasured privacy percentage.

8.2 Private Collateral and the Liquidation Paradox

Private collateral is where the design nearly breaks. A healthy lending market needs liquidators to discover unhealthy positions quickly. If positions are opaque commitments, who knows which one to liquidate? Research on shielded-UTXO DeFi shows how public constraints and later unshielding can shrink the set of possible original owners [17]; hiding a note is not the same as hiding its history.

I see four imperfect approaches. A threshold proof can show that a member of a commitment set violates the collateral rule, but the set and proof schedule may reveal population or timing information, and someone still needs the witness. A keeper lottery can assign attempts without publishing every owner, but failures waste resources and delay liquidation. An encrypted registry can let approved keepers locate positions, yet its decryption group becomes a trusted correlation surface. A delegated privacy pool makes the same trade-off in institutional form.

There is no clean victory here. Liquidation requires object discovery, so an application must choose among public observability, trusted or threshold monitoring, and added latency. Ephemeral ownership can compartmentalize unrelated positions; it cannot make this requirement disappear. A fair experiment must measure missed or delayed liquidations alongside surviving joins.

8.3 Private Credentials Linked to Value Only When Necessary

W3C credentials distinguish issuer, holder, and verifier, but the presentation layer determines whether repeated use is linkable [13]. Suppose a student proves age to one service, club membership to another, and scholarship eligibility to a third. The ownership-object model binds each action to a scoped capability rather than a public identity. One presentation authorizes one action and is then renewed or discarded.

The verifier may still demand a stable subject identifier, the issuer may collude with verifiers, timing may connect presentations, and revocation may create a common lookup point. I am not claiming this makes credentials anonymous; it does not. What changes is the default: continuity must be requested and justified instead of arriving automatically because the holder reuses one account.

9. Where the Design Fails First

The most important failure modes are not exotic cryptography. Regulated gateways can connect a deposit to a legal identity, and rotation does not erase their records. Timing and amounts can dominate when a distinctive value crosses domains. Batching, delay, and standardized amounts may help, but add latency or liquidity costs.

Application identifiers, including positions, usernames, repeated calls, issuer identifiers, and wallet telemetry, can become substitute accounts. Bridges expose matching assets, amounts, and time windows on two chains. EIP-4844 provides data availability, not confidentiality, so it does not repair this leak [12].

Recovery creates a direct privacy–usability conflict. One hardware root can restore every fragment easily, but one recovery event may reconnect them. Separate compartment roots reduce that join and increase the chance of backup mistakes. BIP-32 simplifies deterministic backup but concentrates root-secret risk; SLIP-39 distributes shares without hiding an on-chain recovery transaction [18], [19]. Social recovery distributes authority, yet a stable contract and guardian actions may expose continuity [20]. Wallets should offer explicit unified and compartmented recovery modes and warn which objects each mode reconnects.

Fragmentation adds its own fingerprints. Regular split counts, synchronized renewal, large merges, broad viewing keys, or one discovery service can reverse the intended effect. This ranking prevents a lower ledger-layer OCE from being described as complete privacy: a design can remove address reuse and still lose immediately at an exchange, application, bridge, or recovery boundary.

10. Implementation and Measurement Plan

The obvious failure points are operational, not cryptographic. Wallet complexity comes first: fragmentation creates more state to discover and recover, and a wallet that mishandles it loses users before privacy matters. Renewal and splitting also add proof work and transaction bytes. Composability is harder to repair because public contracts often assume a stable account. Disclosure and cross-chain use remain separate problems; either can recreate the correlation handle the design removed.

A prototype should compare a persistent-account baseline with 1, 2, 5, 10, and 25 objects under identical workloads. The sequence samples small operating points and uses 25 only as a stress endpoint, not a recommended setting. The evaluator should publish observer models, join features, weights in C, and success criteria, then measure bytes, proof and verification time, local scanning, storage, recovery steps, linkage errors, and liquidation delay.

Gas claims must be tied to a concrete circuit. EIP-197 and EIP-1108 provide a verifiable pairing-precompile schedule; four pairings cost 45,000 + 4 × 34,000 = 181,000 gas for the pairing call alone [24]. That is not the cost of five fragments and cannot simply be multiplied without specifying aggregation and contract overhead. A prototype must measure its actual verifier rather than turn a precompile formula into a fictional benchmark.

A useful result may be negative: continuity reduction could flatten while operational costs rise, or timing could overwhelm address rotation. That would still show where engineering effort belongs.

11. Conclusion

The pieces already exist. Zcash and Aztec consume private state and create fresh state; Monero and stealth-address schemes reduce receiver linkage; W3C credentials separate possession from selective disclosure [4], [5], [8], [7], [13]. I put them under one question: after the original ownership representation disappears, can an observer still reconstruct the person who keeps controlling the asset?

I do not know the answer yet. Fragmentation may reduce continuity, or it may move the same problem into recovery, applications, bridges, and behavior. That is why I treat this as a research programme rather than a finished protocol. The four constructs expose the compromises, and the Ledger Lens asks where durable control belongs when public ownership is intentionally less durable.

Here is the bet: if a ledger stops recording who owns things over time, not just what happened but who it kept happening to, an analyst loses one of the most durable handles available. Whether that gain is worth the engineering cost is what a prototype needs to answer. I think it is worth finding out.

1. A. Pfitzmann and M. Hansen, “A terminology for talking about privacy by data minimization: Anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity management,” v0.34, Aug. 2010. ietf.org/archive/id/draft-hansen-privacy-terminology-00.html
2. L. Sweeney, “k-anonymity: A model for protecting privacy,” Int. J. Uncertainty, Fuzziness and Knowledge-Based Systems, vol. 10, no. 5, pp. 557–570, 2002. doi.org/10.1142/S0218488502001648
3. C. Dwork, “Differential privacy,” in Proc. ICALP, 2006, pp. 1–12. doi.org/10.1007/11787006_1
4. D.-E. Hopwood, S. Bowe, T. Hornby, and N. Wilcox, “Zcash protocol specification,” Zerocoin Electric Coin Company, 2026. zips.z.cash/protocol/protocol.pdf; see also ZIP 224, zips.z.cash/zip-0224
5. S. Noether, A. Mackenzie, and the Monero Core Team, “Ring confidential transactions,” Monero Research Lab, MRL-0005, Feb. 2016. getmonero.org/resources/research-lab/pubs/MRL-0005.pdf
6. Aleo Network Foundation, “Public and Private State,” Aleo Documentation, 2026. docs.aleo.org/learn/core-concepts/public-and-private-state
7. Aztec Labs, “State management: Public state, private notes, and nullifiers,” 2026. docs.aztec.network/developers/docs/foundational-topics/state_management
8. T. Wahrstätter, M. Solomon, B. DiFrancesco, and V. Buterin, “ERC-5564: Stealth Addresses,” Ethereum Improvement Proposals, 2022. eips.ethereum.org/EIPS/eip-5564
9. M. Solomon, T. Wahrstätter, B. DiFrancesco, V. Buterin, and G. Ghayrat, “ERC-6538: Stealth Meta-Address Registry,” Ethereum Improvement Proposals, 2023. eips.ethereum.org/EIPS/eip-6538
10. V. Buterin, S. Wilson, A. Dietrichs, and lightclient, “EIP-7702: Set Code for EOAs,” Ethereum Improvement Proposals, 2024. eips.ethereum.org/EIPS/eip-7702
11. Y. Weiss et al., “ERC-4337: Account abstraction using alt mempool,” Ethereum Improvement Proposals, 2021. eips.ethereum.org/EIPS/eip-4337
12. V. Buterin et al., “EIP-4844: Shard blob transactions,” Ethereum Improvement Proposals, 2022. eips.ethereum.org/EIPS/eip-4844
13. M. Sporny, D. Longley, and D. Chadwick, Eds., “Verifiable Credentials Data Model v2.0,” W3C Recommendation, May 15, 2025. w3.org/TR/vc-data-model-2.0
14. B. Ofem, “Exploring ownership fragmentation as a privacy primitive for the post-Pectra EVM,” Ethereum Research, Jun. 16, 2026. ethresear.ch/t/25213
15. S. Jamwal, J. Cano, G. M. Lee, N. H. Tran, and N. Truong, “A survey on Ethereum pseudonymity: Techniques, challenges, and future directions,” J. Network and Computer Applications, vol. 232, Art. no. 104019, 2024. doi.org/10.1016/j.jnca.2024.104019
16. Y. Tang, C. Xu, C. Zhang, Y. Wu, and L. Zhu, “Analysis of address linkability in Tornado Cash on Ethereum,” in Cyber Security, CCIS 1506, Springer, 2022, pp. 39–50. doi.org/10.1007/978-981-16-9229-1_3
17. H. Guo, S. Chaliasos, Y. Feng, and J. Xu, “The anonymity gap: Understanding real privacy in shielded UTXO-based protocols for DeFi,” arXiv:2608.22987, Aug. 2026. arxiv.org/abs/2608.22987
18. P. Wuille, “BIP-32: Hierarchical deterministic wallets,” Bitcoin Improvement Proposals, 2012. github.com/bitcoin/bips/…bip-0032.mediawiki
19. M. Palatinus, P. Rusnak, A. Voisine, and S. Bowe, “SLIP-0039: Shamir’s Secret-Sharing for Mnemonic Codes,” SatoshiLabs Improvement Proposals, 2017. github.com/satoshilabs/slips/…slip-0039.md
20. V. Buterin, “Why we need wide adoption of social recovery wallets,” Jan. 11, 2021. vitalik.eth.limo/general/2021/01/11/recovery.html
21. Ledger, “New in Ledger Wallet: Secure private transactions with Aleo,” May 18, 2026. ledger.com/new-in-ledger-wallet-secure-private-transactions-with-aleo
22. Ledger Developer Portal, “Aleo signer reference,” 2026. developers.ledger.com/docs/device-interaction/dmk-ts/references/signers/aleo
23. Ledger, “The Secure Element Chip: How It Keeps Your Ledger Secure,” Ledger Academy, updated Jan. 29, 2026. ledger.com/academy/security/the-secure-element-whistanding-security-attacks
24. V. Buterin and C. Reitwiessner, “EIP-197: Pairing check precompile,” 2017, eips.ethereum.org/EIPS/eip-197; A. Chatterjee, M. Krupp, and D. Feist, “EIP-1108: Reduce alt_bn128 precompile gas costs,” 2018, eips.ethereum.org/EIPS/eip-1108

I confirm that this paper represents my own research, analysis, synthesis, and editorial judgment. I used AI-based tools for literature discovery, reference checking, drafting, and layout. I reviewed the sources independently and take full responsibility for the argument, examples, figures, and conclusions. I have not presented generated examples or unperformed experiments as results. I identify closely related work, including GhostShard. This is a solo submission.

Hano Diony Jacob  ·  September 2026