Custody Proof for Tokenized Assets: Beyond Merkle Trees

After FTX collapsed in November 2022, the crypto industry rallied around Proof of Reserves (PoR). Exchanges published Merkle trees showing that customer deposits existed on-chain. The idea was simple: if an exchange can prove that it holds the assets it claims to hold, customers can trust that their funds are safe. Binance, Kraken, OKX, and others published PoR reports within weeks. The Merkle tree became the symbol of transparency.

But Merkle trees solve only half the problem. A Merkle tree proves inclusion -- that a specific balance is part of a specific set of balances. It proves that "account A has X BTC" is included in the tree whose root is R. It does not prove where the BTC came from. It does not prove how X was calculated. It does not prove that the valuation methodology is correct. And it does not prove that the proof itself has not been selectively generated -- showing one tree to auditors and another to the public. For simple cryptocurrency custody, inclusion proof may be sufficient. For tokenized real-world assets, it is not even close.

Tokenized assets introduce a computation layer that Merkle trees cannot address. The value of a tokenized real estate token is not its on-chain balance. It is the result of a NAV computation that takes dozens of inputs: property appraisals, rental income, operating expenses, debt service, FX rates, management fees, and more. Proving that the token exists on-chain proves nothing about whether it is correctly valued. A custodian of tokenized assets must prove not just that the assets exist, but that the valuation computation was correct, that the inputs were authentic, and that nothing has been modified since the computation ran.

What Custody Actually Requires for Tokenized Assets

A qualified custodian for tokenized securities has obligations that go far beyond holding private keys. SEC regulations require custodians to maintain accurate records, provide regular statements, ensure proper valuation, and segregate client assets. The custody requirement is not "prove you hold the tokens." It is "prove you hold the tokens, prove they are correctly valued, prove the valuation methodology is documented and followed, prove the records are tamper-evident, and prove all of this at any point in time over a multi-year retention period."

This breaks down into four distinct proof obligations. First, existence proof: the assets exist and are under the custodian's control. Merkle trees handle this for on-chain assets. Second, valuation proof: the assets are correctly valued using an approved methodology with authentic inputs. This requires computation fingerprinting. Third, integrity proof: the records have not been modified since they were created. This requires cryptographic signatures and hash chains. Fourth, temporal proof: the proofs can be verified at any point in time, including retroactively. This requires temporal versioning.

Standard PoR addresses only the first obligation. Cachee adds the other three.

The Computation Layer: What Merkle Trees Miss

Consider a custodian holding $500 million in tokenized commercial real estate. The portfolio contains 47 properties across three countries. Each property has a current appraisal, a rental income stream, operating expenses, and debt service. The total portfolio value is the sum of the individual property NAVs, minus fund-level expenses, plus cash holdings. This computation happens daily, sometimes hourly for assets with high trading volume.

A Merkle tree can prove that the custodian holds 1,000,000 tokens and that the NAV per token is $500.00, giving a total portfolio value of $500 million. But the Merkle tree says nothing about how $500.00 was derived. Was the property at 123 Main Street valued at $50 million based on a recent appraisal, or was it $50 million based on a three-year-old appraisal that no longer reflects market conditions? Was the EUR/USD rate used for the Frankfurt properties the current rate, or last week's rate? Did the NAV computation include the $2 million roof repair that was invoiced last Tuesday?

These questions matter because the value of the token depends on the answers. If the appraisal is stale, the token is mispriced. If the FX rate is wrong, the token is mispriced. If an expense is excluded, the token is mispriced. And if the token is mispriced, every investor who bought or sold at that price was harmed. The custodian's obligation is not just to hold the assets. It is to ensure that the assets are correctly valued, and to prove that correct valuation to auditors, regulators, and investors.

Cachee: Adding the Computation Proof Layer

Cachee adds computation proofs on top of existing Merkle tree infrastructure. The Merkle tree continues to prove inclusion -- that a specific balance or NAV is part of a specific set. Cachee adds the proof that the NAV was correctly computed from specific, identified, timestamped inputs using a specific, versioned methodology.

Computation Fingerprint for Custody

Every valuation computation performed by the custodian is cached with a computation fingerprint. The fingerprint includes: the hash of all input data (property appraisals, rental income, expenses, debt, FX rates, cash), the methodology version, the fee parameters, the data source identifiers, and the timestamp. The fingerprint is SHA3-256(inputs_hash || methodology_version || parameters || sources || timestamp). This fingerprint uniquely identifies the computation. If any input changes, the fingerprint changes. If the methodology changes, the fingerprint changes.

The computation result (the NAV) is then signed by three independent post-quantum signature algorithms: ML-DSA-65 (lattice-based), FALCON-512 (NTRU lattice-based), and SLH-DSA-SHA2-128f-simple (hash-based). Three signature families provide cryptographic agility: if one PQ algorithm is found to have a weakness, the other two still provide assurance. An attacker would need to break MLWE lattice assumptions, NTRU lattice assumptions, and stateless hash function assumptions simultaneously to forge a custody proof. This is the kind of defense-in-depth that institutional custodians require.

Binding Merkle Inclusion to Computation Proof

The key architectural insight is that the Merkle tree leaf is not just the NAV value. It is the NAV value plus the computation fingerprint. This means the Merkle proof does not just prove "this NAV is part of the reserve." It proves "this NAV, computed from these inputs using this methodology and signed by these three PQ algorithms, is part of the reserve." The Merkle tree provides the set membership proof. The fingerprint provides the computation proof. The PQ signatures provide the integrity proof. Together, they prove existence, valuation, and integrity in a single, self-contained proof structure.

The combined proof works as follows. The custodian publishes a Merkle root R at time T. An investor or auditor wants to verify that fund Alpha is included in the reserve with NAV of $12.47 per token. The custodian provides a Merkle proof showing that the leaf containing (fund_id=alpha, nav_per_token=12.47, fingerprint=FP) is included under root R. The auditor then uses the fingerprint FP to retrieve the computation inputs from Cachee, re-runs the NAV calculation, and verifies that the result matches $12.47. The auditor also verifies the three PQ signatures on the cached entry to confirm that the computation has not been tampered with. No trust in the custodian is required at any step.

Three Signature Families: Cryptographic Agility for Custodians

Custody is a long-duration obligation. A custodian may hold assets for years or decades. During that time, cryptographic algorithms may be broken or weakened. A custody proof that relies on a single signature algorithm is vulnerable to algorithm failure: if that algorithm is broken, every historical proof becomes unverifiable.

Cachee's three-signature approach provides cryptographic agility. Each cached custody computation is signed by three independent algorithms from three independent mathematical families. ML-DSA-65 is based on Module Learning With Errors (MLWE), a lattice problem. FALCON-512 is based on NTRU lattice problems, which are mathematically independent from MLWE. SLH-DSA-SHA2-128f-simple is based on stateless hash functions, which rely on entirely different mathematical foundations than either lattice family.

If a breakthrough weakens one algorithm family, the other two remain valid. The custodian can re-sign historical entries with a replacement algorithm without invalidating the existing proofs. The two valid signatures continue to provide assurance while the replacement is deployed. This is not theoretical: NIST's post-quantum standardization process has already seen candidates weakened or broken during evaluation. Cryptographic agility is not a luxury for custodians. It is a fiduciary requirement.

The three-signature approach also provides defense against implementation bugs. Even if the mathematical foundation of an algorithm is sound, a specific implementation may contain bugs that weaken the signatures. Because the three algorithms are independent implementations with no shared code paths, a bug in one implementation does not affect the other two. An auditor who discovers a signature verification failure on one algorithm can immediately check the other two to determine whether the failure is due to tampering or an implementation issue.

AUDITVERIFY: Independent Custody Verification

The AUDITVERIFY command enables auditors to verify the entire custody computation chain without trusting the custodian. The command takes a fund identifier and a time range, and returns every custody computation performed during that period, each with its computation fingerprint, all three PQ signatures, and the hash chain link to the previous entry.

The auditor's verification workflow is straightforward. First, verify the hash chain: compute the hash of each entry and confirm that it matches the "previous hash" field of the next entry. If any hash does not match, the chain has been tampered with. Second, verify the PQ signatures on each entry: use the custodian's public keys (which are published independently) to verify all three signatures on each entry. If any signature fails, the entry may have been modified. Third, spot-check computation accuracy: select a random sample of entries, retrieve the inputs for each fingerprint, re-run the valuation computation, and verify that the result matches the cached NAV. If the result differs, the computation was either incorrect or the inputs were modified.

This three-step verification process -- chain integrity, signature validity, computation accuracy -- is entirely independent of the custodian. The auditor does not need access to the custodian's infrastructure. They do not need to trust the custodian's systems. They receive a set of CAB bundles (Cache Attestation Bundles), each containing everything needed for independent verification: the cached value, all three PQ signatures, the computation fingerprint, the hash chain links, and the public keys. The auditor's verification is mathematical, not procedural.

# Auditor verification workflow using Cachee CLI

# Step 1: Retrieve custody computation chain for Q1 2026
cachee AUDITVERIFY custody:alpha-fund \
    --start 2026-01-01T00:00:00Z \
    --end 2026-03-31T23:59:59Z \
    --output cab-bundles/

# Step 2: Verify hash chain integrity
cachee CHAINVERIFY cab-bundles/ --verbose
# Output: 2,160 entries verified. Chain integrity: VALID.
# No gaps detected. No modifications detected.

# Step 3: Verify all PQ signatures
cachee SIGVERIFY cab-bundles/ \
    --pubkeys custodian-pubkeys.pem \
    --algorithms ML-DSA-65,FALCON-512,SLH-DSA
# Output: 6,480 signatures verified (3 per entry).
# ML-DSA-65: 2,160/2,160 VALID
# FALCON-512: 2,160/2,160 VALID
# SLH-DSA: 2,160/2,160 VALID

# Step 4: Spot-check computation accuracy (10% sample)
cachee RECOMPUTE cab-bundles/ \
    --sample-rate 0.10 \
    --methodology nav-re-v3.2.1 \
    --tolerance 0.001
# Output: 216 entries recomputed. All within tolerance.
# Max deviation: $0.0003. Mean deviation: $0.00004.

# Step 5: Export audit report
cachee AUDITREPORT cab-bundles/ \
    --format pdf \
    --include chain-verification,signature-verification,recomputation
# Output: audit-report-alpha-fund-Q1-2026.pdf

Temporal Custody Proof: Any Point in Time

Custody obligations extend over years. SEC Rule 17a-4 requires six years of record retention. A regulator might ask: "What was the value of the alpha fund's portfolio on March 15, 2024, and can you prove it?" With a traditional custodian, this question triggers a search through archived spreadsheets, emails, and third-party attestation letters. With Cachee-backed custody, it is a single temporal query.

GETVERSION custody:alpha-fund 2024-03-15T00:00:00Z returns the custody computation that was active on March 15, 2024. The response includes the portfolio NAV, the computation fingerprint (proving which inputs and methodology produced it), all three PQ signatures (proving it has not been modified since), and the hash chain link (proving it has not been inserted or deleted from the history). The regulator can verify all of these independently, at any time, without accessing the custodian's systems.

Temporal custody proof also enables retroactive consistency checks. If a regulator suspects that a custodian modified historical valuations to mask a loss, they can retrieve the temporal history for the relevant period and verify the hash chain. Inserting a modified entry into the middle of the chain would require recomputing every subsequent hash, which would require forging every subsequent signature, which would require breaking three independent PQ algorithms simultaneously. The hash chain makes retroactive modification computationally infeasible, not just administratively difficult.

Multi-Custodian and Sub-Custodian Verification

Large institutional portfolios often involve multiple custodians and sub-custodians. A pension fund might use Custodian A for tokenized real estate, Custodian B for tokenized private credit, and Custodian C for tokenized commodities. Each custodian produces their own custody proofs. The pension fund needs to aggregate these proofs into a single portfolio-level proof.

Cachee handles this with hierarchical custody proofs. Each custodian produces fingerprinted, PQ-signed custody computations for their portion of the portfolio. The pension fund's aggregation computation reads each custodian's cached result (verified by checking the PQ signatures), sums the values, and caches the aggregate with its own fingerprint that includes the fingerprints of each sub-custodian's computation. The aggregate fingerprint is SHA3-256(custodian_A_fingerprint || custodian_B_fingerprint || custodian_C_fingerprint || aggregation_logic_version).

This creates a verification tree. An auditor verifying the aggregate portfolio can trace downward: verify the aggregate fingerprint, then verify each custodian's fingerprint, then verify each custodian's inputs. At every level, the PQ signatures confirm integrity, the fingerprints confirm computation correctness, and the hash chains confirm temporal consistency. No custodian needs to trust any other custodian. No custodian needs to share raw data with any other custodian. The fingerprints and signatures provide inter-custodian verification without inter-custodian data sharing.

Comparison: Standard PoR vs. Computation-Backed Custody

Regulatory Alignment

The SEC's proposed safeguarding rule for investment advisers (released February 2023, still under review) would require qualified custodians to maintain written procedures for the valuation of client assets, produce periodic account statements with verified valuations, and submit to examination of custody records. Cachee-backed custody proofs satisfy each requirement directly: computation fingerprints serve as the "written procedures" (because the methodology version is embedded in every fingerprint), CAB bundles serve as "verified valuations" (because they include signatures and independent verification capability), and the hash-chained audit log serves as the "custody records" available for examination.

MiCA's custody requirements for crypto-asset service providers (Article 70) require segregation of client assets, regular reconciliation, and maintenance of "up-to-date records." The reconciliation requirement maps directly to verifiable state reconciliation. The "up-to-date records" requirement is satisfied by the temporal version store, which maintains a cryptographically committed history of every custody computation. The segregation requirement can be verified through the fingerprinting system: each client's assets have their own fingerprinted computation chain, and cross-client contamination would produce different fingerprints.

Both regulations are moving toward continuous, verifiable custody rather than periodic attestation. The infrastructure to support this does not exist in the traditional custody world. Spreadsheets, dual controls, and quarterly attestation letters are not scalable to continuous verification of tokenized assets that trade 24/7. Cachee provides the infrastructure: every valuation is fingerprinted at computation time, every fingerprint is signed with three PQ algorithms, every computation is chained into a tamper-evident history, and every point in time is queryable with cryptographic proof. The custody proof is not a report that a custodian produces quarterly. It is a continuous, cryptographic property of every computation the custodian performs.

The Institutional Custody Standard

Institutional investors evaluating custodians for tokenized assets will increasingly demand computation-level proof, not just inclusion-level proof. A pension fund allocating $100 million to tokenized real estate will not accept "we hold the tokens and here is a Merkle proof" as sufficient custody evidence. They will ask: how is the NAV computed, what inputs does it use, can I verify the computation independently, can I query any historical NAV with proof, and what happens if one of your cryptographic algorithms is compromised?

Custodians who can answer these questions with cryptographic proof -- not with procedural descriptions, not with attestation letters, but with independently verifiable mathematics -- will win institutional mandates. Custodians who cannot will be limited to retail custody, where the bar is lower and the margins are thinner.

The path from standard PoR to computation-backed custody is not a product upgrade. It is an infrastructure redesign. Every valuation computation must be fingerprinted. Every fingerprint must be signed. Every computation must be chained. Every chain must be temporally queryable. This is what Cachee provides out of the box: a cache infrastructure where every entry is a self-contained custody proof, produced as a byproduct of normal computation, verifiable by anyone without trusting the custodian. Proof of Reserves was the beginning. Proof of Computation is the standard that tokenized assets require.