We built ZKValue (zkvalue.com) to bring verifiable computation to private credit — a $1.7T asset class where NAV is still calculated in spreadsheets and "verified" by committee sign-off.
The core problem: there's no mathematical object proving that specific inputs, through a specific algorithm, produced specific outputs — with nothing modified after the fact. An LP asking how NAV was calculated gets a quarterly PDF.
What we built:
Deterministic computation — NAV, LTV, DSCR, covenant compliance, concentration analysis. Same inputs always produce the same hash. Any external party with the original loan tape can independently verify.
Dual-layer fraud detection — seven rule-based checks (Benford's Law, collateral reuse, DSCR/payment-status consistency, round-number clustering, borrower identity integrity, loan stacking, rate-collateral type mismatch) plus an LLM layer for subtler anomaly patterns. Each loan gets a risk tier and confidence score. Both layers are proof-hashed.
Cryptographic proofs — SHA-256 Merkle-rooted proof hash over inputs and outputs. Tamper-evident, deterministic, independently verifiable.
On-chain anchoring — daily proof batches on Polygon. Immutable public timestamps.
Continuous monitoring — daily/weekly re-verification with graded drift alerts instead of quarterly snapshots.
Stress testing — Monte Carlo (up to 10k runs, correlated sampling). VaR 95/99, CVaR, NAV distributions. All proof-hashed.
What we're building next: source data verification via servicing platform and bank API integration (proving the data, not just the math), and cross-institution collateral detection.
Technical questions welcome. Happy to discuss the fraud detection architecture or the proof generation pipeline specifically.
---
ASK HN (for discussion, not promotion):
Title: Ask HN: Why hasn't verifiable computation been adopted in private credit NAV?
Body:
Private credit is a $1.7T market. NAV is calculated using spreadsheet models with assumptions that can't be independently verified by LPs. Audit trails live in email. Covenant monitoring is quarterly.
The technical solution seems straightforward: deterministic computation + cryptographic proof generation + on-chain anchoring. Same inputs → same hash → any party can verify → any modification is detectable.
We're building exactly this at ZKValue. But I'm curious what the HN community thinks the actual adoption barriers are. Is it:
— Funds don't want the transparency (opacity is a feature, not a bug)
— LP sophistication hasn't demanded it yet
— Regulatory frameworks haven't caught up
— Integration with legacy servicing infrastructure is the hard problem
saltyoldman•1h ago
It seems crazy to me that the only indicator of a "good economy" is the stock market or jobs.
What we actually need is a mixed indicator that combines avg household size + private credit + employee age ranges and finally stock market and job data to know if the economy is doing well.
smmaan•1h ago
The core problem: there's no mathematical object proving that specific inputs, through a specific algorithm, produced specific outputs — with nothing modified after the fact. An LP asking how NAV was calculated gets a quarterly PDF.
What we built:
Deterministic computation — NAV, LTV, DSCR, covenant compliance, concentration analysis. Same inputs always produce the same hash. Any external party with the original loan tape can independently verify.
Dual-layer fraud detection — seven rule-based checks (Benford's Law, collateral reuse, DSCR/payment-status consistency, round-number clustering, borrower identity integrity, loan stacking, rate-collateral type mismatch) plus an LLM layer for subtler anomaly patterns. Each loan gets a risk tier and confidence score. Both layers are proof-hashed.
Cryptographic proofs — SHA-256 Merkle-rooted proof hash over inputs and outputs. Tamper-evident, deterministic, independently verifiable.
On-chain anchoring — daily proof batches on Polygon. Immutable public timestamps.
Continuous monitoring — daily/weekly re-verification with graded drift alerts instead of quarterly snapshots.
Stress testing — Monte Carlo (up to 10k runs, correlated sampling). VaR 95/99, CVaR, NAV distributions. All proof-hashed.
What we're building next: source data verification via servicing platform and bank API integration (proving the data, not just the math), and cross-institution collateral detection.
Technical questions welcome. Happy to discuss the fraud detection architecture or the proof generation pipeline specifically.
---
ASK HN (for discussion, not promotion):
Title: Ask HN: Why hasn't verifiable computation been adopted in private credit NAV?
Body: Private credit is a $1.7T market. NAV is calculated using spreadsheet models with assumptions that can't be independently verified by LPs. Audit trails live in email. Covenant monitoring is quarterly.
The technical solution seems straightforward: deterministic computation + cryptographic proof generation + on-chain anchoring. Same inputs → same hash → any party can verify → any modification is detectable.
We're building exactly this at ZKValue. But I'm curious what the HN community thinks the actual adoption barriers are. Is it:
— Funds don't want the transparency (opacity is a feature, not a bug) — LP sophistication hasn't demanded it yet — Regulatory frameworks haven't caught up — Integration with legacy servicing infrastructure is the hard problem