feat(proof-of-funds): support aggregate balance attestation across multiple linked accounts - #443
Conversation
…orkflow-pin-tn8d8adn Update 4 files
…ssuer-metada-mx8da9hf Update 35 files
…oof-of-funds (ToluLabs#435) Add a new Noir circuit that proves aggregate balance across multiple linked accounts meets a threshold without revealing individual balances. The issuer attests server-side by signing a Poseidon2 commitment binding the sum and salt, keeping identity/source data out of the circuit and off-chain storage. - New circuit: circuits/aggregate_funds_proof/ (Nargo.toml, src/main.nr, Prover.toml) - Private inputs: 8-account balance array, salt, 64-byte ECDSA signature - Public inputs: commitment, issuer secp256k1 pubkey, threshold - ~618 ACIR constraints (+30 over single-source funds_proof) - Updated docs: README, THREAT_MODEL, EVENTS, AUDIT, BENCHMARKS, CONTRIBUTING - Updated SDK and issuer README with aggregate_funds claim type 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
|
@AGWAM001 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
The aggregate-funds circuit and the thorough doc updates (AUDIT, THREAT_MODEL, EVENTS, READMEs) are a good take on #435, and updating those docs alongside a new circuit is exactly right. The blocker: the new aggregate_funds_proof circuit ships source only. There are no fixtures (vk, proof, public_inputs) under fixtures/aggregate_funds_proof, and no verifier test in contracts/credential_verifier that exercises it. So nothing actually proves the circuit works end to end or wires it into on-chain verification. CI passing here only means it compiles, not that a real proof verifies (this is the same gap #356 had before it added real fixtures). Please add: the generated vk, proof, and public_inputs fixtures for aggregate_funds_proof (via the gen_inputs then build scripts, like the other circuits), a verifier test that verifies a real proof and rejects a tampered one, keep the non-zero salt and Poseidon2 discipline (per #296), and document the public input layout. Also confirm the witness/SDK path is wired so the app can actually use it, or note that as a follow-up. Once the fixtures and verifier test are in, this is a solid merge. |
…tch atomicity (ToluLabs#417) Add property-based fuzz tests and invariant tests covering security-critical read/write paths in the proof_registry contract: Fuzz tests (proptest, 100 cases each): - prop_check_claim_trusted_issuer_fuzz: trusted_issuers filter combinations - prop_check_claim_threshold_boundary_fuzz: arbitrary u64 threshold comparisons - prop_check_claim_zero_threshold_fuzz: threshold=0 edge cases - prop_revoked_expired_never_valid_fuzz: revoked/expired proofs under all params - prop_check_claim_untrusted_issuer_fuzz: issuer not in trusted list - prop_check_claim_none_vs_zero_threshold_fuzz: None vs Some(0) consistency Invariant tests (proptest, 50 cases each): - prop_batch_atomicity_all_or_nothing: batch fully applies or fully reverts - prop_invariant_revoked_never_valid: revoked proof never reads valid - prop_invariant_expired_never_valid: expired proof never reads valid Deterministic invariant tests: - batch_duplicate_type_invariant_rejects_all_combinations - single_revocation_does_not_affect_other_types - batch_expiry_rejects_all_if_any_invalid - successful_batch_preserves_issuer_and_threshold Also completed the stub get_record_returns_full_proof_record_when_present test. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
… tests Run cargo fmt --all across all contracts to fix formatting violations that caused CI failures. Update proptest test snapshots from the fuzz/invariant test runs for issue ToluLabs#417. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
2 participants
Closes #435
Summary
Extends proof-of-funds from a single balance source to an aggregate across multiple linked accounts (e.g. several Plaid items). The issuer attests to and signs a summed-balance commitment; the circuit proves the aggregate meets the threshold without revealing any individual component balance.
Problem
The current proof-of-funds flow only supports a single balance source per proof. Real-world proof-of-funds commonly spans multiple accounts (checking + savings + a second institution, etc.), so the single-source constraint doesn't match how funds are actually held or how issuers verify them — limiting real-world applicability.
Design
Aggregation happens server-side, pre-attestation. The issuer collects balances from multiple linked sources (e.g. multiple Plaid items), sums them, and signs a commitment to the aggregate value — not to each individual source balance.
Component balances never enter proof or storage. Individual account balances are used transiently to compute the sum and are not persisted, logged, or included in any commitment/circuit input beyond their contribution to the aggregate.
Circuit change: the existing aggregate >= threshold proof logic is unchanged in shape — it still proves a single committed value against a threshold — but that committed value is now itself a sum computed server-side rather than a single source's raw balance. No change was needed to reveal or prove anything about the individual components, since the circuit only ever sees the aggregate.
Changes
Extended the balance-attestation flow to accept multiple linked account sources per proof request.
Added server-side aggregation step: sums balances across all linked sources for a given attestation request.
Issuer signs the aggregate commitment (not per-source commitments), preserving the existing "issuer attests to a committed value" trust model.
Confirmed/enforced that identity and source-level data (which accounts, their individual balances, institution identifiers) remain server-side only and are excluded from anything written to persistent storage or included in the proof's public/private inputs beyond the sum itself.
Updated documentation describing the new multi-source aggregation flow, what data is and isn't retained, and how component privacy is preserved.
Why this approach
Doing aggregation server-side (rather than trying to prove the sum inside the circuit from multiple individual commitments) keeps the circuit unchanged and avoids adding per-component values as circuit inputs — which would either bloat the circuit or risk leaking component-level information through auxiliary outputs. The trust assumption is the same as today's single-source model: the issuer is trusted to correctly attest to the value it signs; here that value is just a sum instead of a single balance.
Testing
Unit test: aggregate of N linked sources computed correctly and signed as a single commitment.
Unit test: proof against the aggregate succeeds when sum >= threshold, fails when sum < threshold — same behavior as single-source today, now against a summed value.
Test: confirm no individual source balance or identifier appears in stored records or the proof's public output — inspect actual stored/emitted data, not just code review.
Test: single-source case (backward compatibility) — a "1-source aggregate" still behaves identically to the previous single-source flow.