Payment request
The payment goes through the MusdPay contract, which moves the tokens straight from you to the merchant and records the reference onchain right after the token's own transfer log. The reference then shows up next to the payment on the merchant's MUSD Books statement. MUSD supports permit, so this is a single transaction.
Generate a statement
Statement
Anchor onchain
Record this statement's hash in the StatementRegistry. Anyone can then verify that a CSV they receive is exactly the one you attested, and can re-derive it from chain data. An accountant or lender can co-attest the same hash.
Transfers
| Block | Dir | Kind | Counterparty | Amount | Reference | Tx |
|---|
Verify a statement
Drop in a canonical MUSD Books CSV. It is hashed locally and looked up in the onchain StatementRegistry. You can also re-derive the statement from Mezo chain data and compare it line by line, which proves the contents are true, not just unchanged.
Create a payment request
Generate a link a customer can open to pay you in MUSD with an invoice reference attached. The reference appears next to the payment in your MUSD Books statement, so reconciliation is automatic.
Why MUSD needs its own books
Mezo lets people borrow MUSD against their Bitcoin instead of selling it. That is useful, but it leaves an accounting gap: a borrower, a small business that gets paid in MUSD, and their accountant all need a clean, checkable record of what came in, what went out, what was borrowed and what was repaid. A block explorer shows raw logs. MUSD Books turns them into a statement that can be verified by someone who does not trust the sender.
What a statement contains
- Exact amounts. Every
Transferof the token is counted once at full 18-decimal precision, usingBigInt. - Reconciliation to the last unit.
opening + in − outis compared with the onchain balance at the end of the period (read withbalanceOfat the exact opening and closing blocks). For a plain ERC-20 like MUSD the difference is zero, and the statement says so. A non-zero value would expose a rebasing or fee-on-transfer token. - Mezo-aware labels. Tokens newly minted to the account are marked
mint(for a Trove owner this is a loan draw; for protocol accounts it can be fee income) and tokens sent to the zero address are markedburn(for a Trove owner, a repayment). Core Mezo contracts such as BorrowerOperations, StabilityPool and PCV are named. - Invoice references. Mezo has no memo precompile.
MusdPaymoves tokens withtransferFromand emitsPaymentReferenceas the log immediately after the token's ownTransfer. The statement joins the two by log position, requiring payer, merchant and amount to match. - Deterministic CSV. The same address, token and block range always produce the same bytes, so the keccak256 hash identifies the statement.
Anchoring and verification
The hash can be anchored in StatementRegistry (several parties can attest the same hash). Verification is one view call plus an optional re-derivation from public chain data. Nothing leaves your browser except RPC calls.
Contracts
StatementRegistry:
MusdPay:
MUSD Books is a bookkeeping aid, not tax or legal advice. Source: github.com/neimasilk/musd-books. It extends the author's earlier project ArcBooks (Arc network).