Skip to main content
The receipt_registry contract combines the previous receipt-related contracts into one simpler MVP deployment. It handles:
  • Payment receipt proof metadata.
  • Duplicate receipt hash rejection.
  • Owner receipt indexes.
  • Receipt hash verification.
  • Receipt access grants and revocations.
  • Batch anchor records.
  • Receipt-linked dispute records.

​
Why merge this layer?

Receipts, access grants, anchors, and disputes are one product surface for users. Keeping them split across four contracts created more contract IDs, more initialization steps, and more reviewer overhead without improving the protection reserve boundary. The money-path contracts remain separate:
  • protection_engine
  • protected_balance_vault
  • reserve_vault
  • oracle_adapter
That keeps custody, reserve accounting, and oracle trust boundaries easier to review.

​
Main methods

Username payments complete first. A wallet-signed receipt transaction is optional and should be shown only after payment success. The app gives users a 10-minute print window; if they click Print receipt, create_receipt() charges the receipt fee and anchors the receipt hash on-chain. For the current MVP, receipt fees route 100% to the configured treasury wallet. No automation split is taken from individual receipt-print fees.

​
Security notes

  • Sender authorization is required to create a receipt.
  • Owner authorization is required to create a receipt, mark it disputed, or manage receipt access.
  • Admin authorization is required for dispute resolution.
  • Receipt metadata is proof-oriented. It should not store raw private payment notes.