Receipt-Rooted Reputation

Status: White paper, draft v1 — 2026-05-19 Authors: DEOS Computing Companions: did:deos v1, a2a-ext/substrate-receipts/v1

Abstract

Reputation on today's web is an artifact of platforms. eBay scores live in eBay's database, Uber's in Uber's, GitHub's in GitHub's. Each is aggregator-controlled, unportable, and silently editable. A user changing platforms cannot bring their reputation; a platform changing its rules rewrites every score without consent.

The Maya substrate produces a different primitive. Every action an agent takes on your behalf yields a signed, log-anchored, optionally Bitcoin-timestamped receipt: a verifiable claim that a specific action was authorized, executed, and observed at a specific time. A stream of receipts is a structured personal history that you carry and that no one else can rewrite.

This paper describes receipt-rooted reputation: how that stream composes, with cryptographic care, into reputation signals that are portable, verifiable, censorship-resistant, and selectively disclosable. It is not a finished system — it is the design space that opens up once receipts exist. Published now, while the substrate is small enough to change, to invite critique.

1. The aggregator problem

A reputation system gathers signal about an actor's past behavior, derives a score, exposes the score to relying parties, and updates as new signal arrives. The classical examples — eBay seller rating, Uber 5-star average, Yelp distribution, FICO, the H-index — share one architecture: a single aggregator holds the signal, computes the derivation, controls the exposure.

That concentration produces five well-documented failure modes.

Lock-in. A reputation accrued on platform A has no meaning on platform B. The seller with 12 years of perfect feedback on eBay starts at zero on Mercari. The driver with 50,000 rides on Uber starts at zero on Lyft. The cost of switching is therefore measured not just in switching effort but in reputation loss — which makes the lock-in self-reinforcing.

Silent rewriting. The aggregator can change the derivation function at any time, retroactively. A 4.8-star average becomes a 4.6 because the platform decided to weight recency differently; a contractor's "verified" badge disappears because a category policy changed. The user has no audit log of why, and no recourse beyond customer support.

Sybil resistance through gatekeeping. Because the aggregator is the only authority, the easiest way to prevent fake reputation is to make accounts costly to create — KYC, phone verification, deposit holds. This raises the floor for legitimate users alongside the bad ones, and it concentrates personhood-judgment in the same entity that judges reputation.

Information asymmetry. The aggregator sees every signal. The relying party (the buyer, the rider, the lender) sees only the derived score. Useful structure — this seller is 4.8 stars on electronics but 3.2 stars on clothing — is collapsed into a single number. Relying parties cannot pose their own questions; they can only consume the answers.

No interoperability with capability. A reputation score says "this actor has behaved well in the past." A capability says "this actor is currently authorized to do X." They are designed independently and rarely composed. In a world where agents act on users' behalf, the more interesting object is "I have authorized my agent to spend up to $200 and the counterparty has a strong history of completing $200 transactions cleanly" — a joint claim that today requires two separate, incompatible systems.

These failures are not bugs. They are properties of the architecture. A single aggregator with full custody of the signal cannot avoid them.

2. What receipts make possible

A substrate receipt (see a2a-ext/substrate-receipts/v1) records, for one completed action:

• The capability that authorized it. A UCAN chain whose leaf granted exactly the action the agent took. The user, the agent, and the counterparty are each identified by a did:deos.
• The action's content-addressed shape. Action type, parameters, result digest. Not the secret payload — the commitments over the payload, so the receipt is meaningful without violating selective disclosure.
• A substrate Ed25519 signature binding all of the above, plus a timestamp.
• An MMR inclusion proof placing the receipt at a specific position in an append-only log whose root is published.
• Optionally, an OpenTimestamps proof committing the log root to a Bitcoin block — the receipt then carries "exists before block N" as a falsifiable claim.

A single receipt does not say "this actor has good reputation." It says "this actor authorized this exact action, and that action executed, at this exact time, and the substrate witnessed it." Reputation is a function over the stream of such receipts — and the user, not the platform, holds the stream.

The rest of this paper makes the right-hand column concrete.

3. Derivation models

A reputation function R(actor, query) → score reads a subset of receipts and produces an output. Because the actors do not control R, relying parties can pose their own questions instead of consuming a single global score.

Five derivations follow. Each is a function over public (or selectively disclosed) receipts and the relying party's policy. None requires the actor's cooperation beyond signing the receipts.

3.1 Frequency

The simplest derivation: how often has this actor completed actions of type X with counterparty Y in the last T seconds?

R_freq(actor, action_type, since) :=
  | { r in receipts : r.principal == actor
                       and r.action.type == action_type
                       and r.issued_at >= since } |

This is already more useful than a 5-star average. It does not flatten frequency, recency, and counterparty mix into one number. A relying party asks "has this agent completed three Amazon purchases in the last 30 days?" instead of "is this agent at 4.8 stars?" — and the answer is a falsifiable claim.

3.2 Counter-party attestation graph

A receipt has a principal (who authorized), a subject (who acted), and an implicit counterparty in the action target. Lift receipts into a graph: a directed edge from A to B if A's receipt logs an action against B. Edges carry timestamps, action types, and result digests.

Standard centrality measures (PageRank, EigenTrust) apply directly. The novelty is not the algorithm — the inputs are verifiable. Anyone replaying the receipts gets the same graph and the same centrality scores. No trusted aggregator computes PageRank over hidden data.

3.3 Outcome-conditioned slashing

A receipt at action time is a forward claim — "this action was authorized and executed." Many actions admit a later outcome receipt: the delivery, the refund, the dispute resolution. If the outcome contradicts the action — package never arrived, payment reversed, contractor disputed — the relying party computes reputation as a ratio of unchallenged to disputed actions, weighted by value at stake.

The slashing here is not literal stake-burning (no on-chain bond). It is evidence-burning: a counterparty with a long log of disputed receipts cannot hide them, because the receipts are signed by the actors who hold them, not by the counterparty. The counterparty cannot rewrite. They can stop accumulating bad ones only by behaving better.

3.4 Time-decayed reputation

Reputation functions usually weight recent behavior more heavily than old. Timestamped receipts — and especially Bitcoin-anchored timestamps — make this computable from the raw signal, without taking the actor's word for when something happened. A simple form:

R_decay(actor, query, now, halflife) :=
  Σ_{r in matching}  exp( -(now - r.issued_at) * ln(2) / halflife )

Bitcoin anchoring matters here. A receipt that claims to be from 2024 but was first witnessed in a Bitcoin block from 2026 cannot honestly contribute to "actor has been active since 2024" reputation. The OTS anchor turns timestamps from advisory to falsifiable.

3.5 Capability-bounded reputation

Because each receipt carries the UCAN chain that authorized it, a reputation query can be bounded by capability:

"Show me this agent's track record specifically on commerce.purchase actions ≤ $50, in 2026."

R_cap(actor, capability_predicate, range) filters receipts whose leaf UCAN attenuation satisfies capability_predicate. The relying party sees the actor's behavior within the same authorization shape they are about to grant. A merchant offering $500 credit does not care about a $5 micro-transaction history; a $5 vending machine does not need the actor's $50,000 procurement history.

Aggregator systems cannot compose this way. Receipt and authorization live in the same envelope here.

4. Threat model

Four threat classes. None is fully closed by receipts alone; each pairs with a complementary primitive.

4.1 Sybil

An attacker creates many did:deos identities and inflates each one's reputation via mutual or self-issued receipts. Receipts alone do not prevent this. They restrict it: the receipts must be issued by counterparties, not by the attacker, to count as observed-action receipts. A sybil that interacts only with other sybils generates a closed subgraph; centrality measures (§3.2) discount such closed subgraphs by construction.

The structural answer is to compose with personhood (proof-of-human, government-attested DID, or social-trust-graph entry-point). The receipt layer carries the personhood proof — DID resolution can require a verifiable credential attesting personhood — but does not generate it. We treat personhood as L1 (see the Stack section of projectmaya) and reputation as a function over L3 receipts.

4.2 Receipt collusion

A counterparty issues fake-but-signed receipts attesting that they completed actions they did not actually execute. The substrate's signature only binds the receipt's claims, not the underlying physical truth.

Two defenses. First, replay: many actions are replay-verifiable — the receipt commits to its inputs, so a relying party can re-execute the action's code path against those commitments and check the output matches. Code that violates this property (e.g. "shipped a package") needs an out-of-band witness — a courier receipt, a recipient sign-off — which itself is a receipt.

Second, second-order disputes. Maya's substrate supports counter-receipts: the principal who is implicated in a fraudulent receipt can issue a signed contradiction. The contradiction does not erase the original (the MMR is append-only) but it does flag it. Reputation derivations that ignore contradiction count are themselves derivation-quality bugs.

4.3 Rug-pull (counterparty disappears)

A counterparty with great reputation suddenly stops responding, leaving open commitments. Aggregator systems handle this with charge-back rights and account suspension. Receipt-rooted reputation handles it the same way charge-backs do today, but on the user's terms: the user holds both the action receipt and the absence of an outcome receipt within the expected window. That gap is itself signal.

Where there is settlement involved (conditional escrow, FedNow / RTP rails, stablecoin escrow), the absence of an outcome receipt can trigger a refund clause directly. This is L5 settlement composed with L3 receipts; we describe the composition pattern in maya-a2a-integration and leave the specific escrow primitive to settlement-layer specs.

4.4 Coercion / private threat

An attacker pressures a user into issuing receipts attesting to coercion-compatible behavior. This is the hardest threat. We do not claim to solve it. Two partial mitigations: the substrate's MMR is append-only, so coerced receipts cannot be hidden by erasure; and the substrate supports deactivation tombstones on DIDs, which allow a user under duress to deactivate compromised keys without erasing history.

The fundamental answer here is the same as in any signature-based system: protect the keys, with hardware (Secure Enclave, YubiKey), with social recovery, with deactivation policies. The receipt layer makes the threat visible (a sudden burst of out-of-character receipts looks structurally different from normal behavior) but cannot prevent it at issue time.

5. Composition with selective disclosure and ZK

A receipt's plaintext content is small and structured. Actions, capabilities, and timestamps are designed for selective disclosure: a user can prove a property over their receipts without revealing the receipts themselves.

Given a receipt log R = [r_1, r_2, ..., r_n] with substrate-signed MMR root root, the user can produce:

• Inclusion ZK proof: "I have ≥ 30 receipts under MMR root root, all with action type commerce.purchase, all from 2025–2026" — without revealing which 30 or what they were.
• Range proof on aggregates: "The sum of action.amount across my 2026 receipts is between $5,000 and $50,000" — without revealing individual amounts.
• Predicate proof on counterparties: "I have ≥ 3 distinct counterparty did:deos values in my matching receipts" — without revealing which.
• Threshold-set proof: "≥ 5 of my last 100 commerce.purchase receipts have outcome=disputed" or "≤ 1 of my last 100 have outcome=disputed" — sensitive enough to require ZK rather than disclosure.

None of these are novel ZK constructions. They are off-the-shelf — Bulletproofs, PLONKish range proofs, signed-Merkle-tree predicate circuits — applied to a structured object. The substrate's contribution is producing the structured object. The reputation function R becomes a circuit the user can selectively evaluate.

Privacy-wise: a user need not publish receipts to gain reputation. They prove derived properties on demand to a relying party of their choosing. Aggregator systems cannot do this — the aggregator sees the raw signal. Receipt-rooted systems can, because the signal is user-custody from the moment it is created.

6. Comparison with existing systems

We are not the first to think about decentralized reputation. The closest priors:

PageRank / EigenTrust. Graph-centrality measures over signed-action graphs. The math is sound; the missing layer has always been "where do the signed actions come from, who holds them, and how does a third party verify them?" EigenTrust assumes a P2P network with mutually-distrusting peers; receipts give that network a real artifact to gossip about. We see receipt-rooted reputation as EigenTrust with verifiable inputs.

eBay/Yelp/Uber 5-star. Single-aggregator, single-axis, opaque derivation. The architectural opposite. Worth mentioning because it dominates current practice and because users have learned to read its specific distortions (5.0 ≈ "as expected", 4.0 ≈ "noticeably bad"). Receipt-rooted reputation will go through a similar literacy curve; relying parties will need help knowing what derivation function to ask for. SDKs and reference UIs should ship with sensible defaults.

Verifiable Credentials (VC). W3C-standardized signed claims about a subject by an issuer. Closest in spirit to substrate receipts. Difference: a VC is a first-party assertion ("I, Alice, claim Bob is a verified buyer"); a substrate receipt is an observed-action record ("I, the substrate, witnessed Bob's agent perform action X with capability Y at time T"). Reputation derived from VCs requires trusting the VC issuer. Reputation derived from receipts requires trusting the substrate's witness function — which is replay-verifiable.

VCs and receipts compose. A did:deos document can embed VCs as service endpoints; receipts can reference VCs in their metadata for credential-conditional flows ("only fulfill if the buyer holds a verified-age VC"). We expect mature systems to use both.

Lens reputation, Farcaster reputation, on-chain Web3 reputation. Reputation graphs derived from on-chain action history. Architecturally compatible; the differences are which substrate witnesses (a blockchain vs. a Maya substrate), which actions count (Lens "casts" vs. arbitrary signed actions), and where the user's identity lives (one chain vs. portable did:deos). We see these as other instances of receipt-rooted reputation, with different deployment constraints. Cross-substrate composition is open work (§7).

GitHub stars, OSS contributor graphs. Probably the cleanest existing approximation. Every commit is a signed action by a real DID-equivalent (the SSH/GPG key), every repository is the substrate, the contribution graph is computable by anyone. The limits — single-vendor custody, no portability, no selective disclosure — are the limits we are trying to remove for the next layer.

7. Open questions

The system as described is workable in v1 but unfinished. We list the questions that materially block production deployment.

Cross-substrate composition. A given did:deos may interact with multiple substrates (the user's home substrate, the counterparty's substrate, an exchange's substrate). Reputation derived from a receipt log spread across substrates needs federation. v1.1 of did:deos introduces a federation manifest (see §12). Reputation tooling has not yet been written.

Quality of derivation function. What does the SDK ship as default R(actor, query)? An incorrect default will be over-trusted. We expect to ship a small library of named derivations (R_freq, R_decay, R_capability_bounded) and to refuse to ship a single "the reputation score." Relying parties choose.

Counter-receipt protocols. Mentioned in §4.2. The substrate supports issuing them; the protocol for when a counter-receipt is issued, validated, and how it affects derivations is unspecified. Likely the right answer is per-derivation-function: each R says how it treats contradictions.

Anchor cost economics. Bitcoin anchoring via OpenTimestamps is currently free at the OTS calendar tier and Bitcoin-fee-bounded at the upgrade tier. As receipt volumes scale, this changes. Substrate operators will need to make explicit choices about anchor cadence, batching, and which receipts (which capability shapes) merit BTC anchoring vs. OTS-pending-only. Reputation derivations should treat anchor status as a first-class signal.

Personhood entry-point. A reputation system that admits sybils has no floor. The receipt layer does not generate personhood; it carries it. The choice of personhood primitive — Worldcoin, BrightID, government VC, social-graph attestation, deposit-bonded entry — is a deployment decision per substrate operator. This paper does not recommend one; production deployments must choose and disclose.

Adversarial economic models. A counterparty colludes with N users to issue mutual high-reputation receipts (a "wash trading" attack on reputation rather than markets). What is the minimum N? What centrality measures resist it? Empirical work on signed-action graphs is sparse compared to e.g. proof-of-stake adversary modeling. We will fund a literature survey and a sample-implementation study in 2026 H2.

Privacy budget. Even with ZK selective disclosure, each disclosure leaks some information. A relying party that interrogates a user's reputation many times learns more than from a single query. Differential-privacy bounds on aggregate disclosures are an open area; we have not specified one.

UX for the relying party. Relying parties today consume a star rating in 200 milliseconds. A capability-bounded receipt-rooted reputation query takes more thought: which derivation, which window, which threshold. The UX challenge is to make this approachable without dumbing it back down to a single number. Likely answer: substrate-aware client libraries that pre-shape common queries.

8. Scope

This paper is a sketch of the design space that opens up once actions produce signed, log-anchored receipts. It explains why receipts are a structurally different reputation primitive than aggregator scores, and what kinds of reputation functions become computable.

It is not a deployment specification. It picks no canonical derivation function. It specifies no ZK circuit suite. It does not solve sybil resistance or personhood. It does not claim Pareto-optimality against existing reputation systems — many use cases (the local barber's regulars list, friend-of-a-friend recommendations) remain well-served by aggregator and informal systems, and probably always will.

The narrow claim: for the agent-to-agent web — programmatic actions, scoped capabilities, remote counterparties, compressed timescales — receipts are a better foundation than aggregator scores, and the design space they open up is worth taking seriously.

This is draft v1, published to invite critique from the cryptographic, mechanism-design, and operations communities. The references list is incomplete relative to the work it draws on; additions welcome.

9. References

• W3C DID Core v1.0. https://www.w3.org/TR/did-core/
• W3C Verifiable Credentials Data Model v2.0. https://www.w3.org/TR/vc-data-model-2.0/
• UCAN Working Group. UCAN v0.10 specification. https://github.com/ucan-wg/spec
• Levien, R. and Aiken, A. Attack-Resistant Trust Metrics. 1998.
• Kamvar, S., Schlosser, M., Garcia-Molina, H. The EigenTrust Algorithm for Reputation Management in P2P Networks. WWW 2003.
• Page, L., Brin, S., Motwani, R., Winograd, T. The PageRank Citation Ranking: Bringing Order to the Web. 1999.
• Resnick, P., Kuwabara, K., Zeckhauser, R., Friedman, E. Reputation systems. Communications of the ACM, 2000.
• Bonneau, J., Bursztein, E., Caron, I., Jackson, R., Williamson, M. Secrets, Lies, and Account Recovery. 2015. (Relevant to §4.4.)
• OpenTimestamps protocol. https://opentimestamps.org/
• Maya substrate (DEOS Computing): working reference implementation; access during v1 alpha is by request.

Maintained by DEOS Computing. License: CC BY 4.0.

Pull requests, line-edits, and counter-arguments to github.com/DEOS-Computing.