This is a profile of the ERC-8004 Reputation Registry for loan outcomes: loans opened, repaid on time, repaid late, defaulted. It adds no core contract. A lender posts ordinary giveFeedback entries with two tags, credit.statement and credit.defaulted, whose files travel inside the entry as data: URIs.
A statement commits, with a Merkle root, to every loan of an agent that closed in a block window at the lender’s contracts. Each leaf names the lender’s own log that closed the loan, so a reader with only an RPC endpoint can rebuild every leaf, the root and the totals, and sample the money that moved. Statements are chained by hash over back-to-back windows, so a skipped window, a revoked statement or a default left out at a declared contract is visible to every reader that rebuilds.
Since this week it also has an optional part, “On-chain manifests, a profile of ERC-8092”: a lender publishes which contracts its writer speaks for as ERC-8092 associations signed by both the lending contract (or its ERC-173 owner) and the writer, so a reader takes the manifest from the chain instead of the writer’s files.
- Text: priors/docs/ERC-8004-CREDIT.md at main · priors-agents/priors · GitHub
- Reference reader, encoding, test vectors and tests: same repository (
sdk/credit-profile.mjs,sdk/credit-reader.mjs,docs/erc-8004-credit/vectors.json)
Questions we would like opinions on:
- Tag names (
credit.statement,credit.defaulted), and whether a lender’s summary score deserves a standard tag. - Recovered amounts after a default, partial repayments and rollovers: a v2 of the leaf, or separate entries?
- Is an ERC-8092 profile the right home for on-chain manifests, or should readers rely on a registry of lenders?
- Readers must not average credit entries with
getSummary(it averages values, it does not add them). Should the profile ask registries for a sum view, or is the reader rule enough?