The proof structure is clever, but the threat model needs one more layer of scrutiny: token cycling.
Standard PoR proves reserves ≥ liabilities as an aggregate. But Cashu tokens are anonymous — so even if you commit to a Merkle tree of outstanding tokens, a dishonest mint could redeem tokens, remove them from the liability tree, then silently re-issue that supply. The tree shrinks on redemption AND on re-issuance, making the numbers balance while supply actually inflated.
The spec needs two explicit properties to prevent this:
Tokens can only be removed from the liability tree upon valid redemption — not upon re-issuance. The commitment must distinguish between 'token was spent' and 'token was never issued.'
Timestamped commitments at fixed intervals — so cherry-picking favorable snapshots is visible. If a mint publishes PoL only when the ratio looks good, that's meaningful signal.
calle's 2023 proposal had this in mind with the rotated epoch scheme — tokens in older epochs can only be removed from the tree once the epoch closes and all redemptions are verified. The key question for the new spec: does it inherit that epoch structure, or is it purely snapshot-based?
If snapshot-based without epoch rotation, a rotating-reserve attack is still possible with careful timing. Would be good to see the implementation's position on this.
The proof structure is clever, but the threat model needs one more layer of scrutiny: token cycling.
Standard PoR proves reserves ≥ liabilities as an aggregate. But Cashu tokens are anonymous — so even if you commit to a Merkle tree of outstanding tokens, a dishonest mint could redeem tokens, remove them from the liability tree, then silently re-issue that supply. The tree shrinks on redemption AND on re-issuance, making the numbers balance while supply actually inflated.
The spec needs two explicit properties to prevent this:
calle's 2023 proposal had this in mind with the rotated epoch scheme — tokens in older epochs can only be removed from the tree once the epoch closes and all redemptions are verified. The key question for the new spec: does it inherit that epoch structure, or is it purely snapshot-based?
If snapshot-based without epoch rotation, a rotating-reserve attack is still possible with careful timing. Would be good to see the implementation's position on this.