# Scoped Continuity: A Reputation Architecture for Anonymous Fractional Settlement

**Draft — TradeP2P**

---

## Abstract

This document describes a reputation architecture for an anonymous peer-to-peer
trading mediator in which settlement is non-custodial, unverified, and
progressive. The design starts from an uncomfortable premise: in such a system,
the mediator cannot observe whether value moved, participants can create
identities for free, and any persistent public identifier is a stronger
deanonymization vector than the ones the underlying transport already goes out
of its way to eliminate.

Most reputation designs respond to this by picking a side — either they abandon
anonymity to get accountability, or they abandon accountability to keep
anonymity. This architecture instead decomposes "reputation" into four
functions that are usually conflated, and scopes each to the narrowest context
that actually requires it. The governing principle:

> **Continuity must be scoped to the smallest context that actually requires
> continuity.**

The result is a system that provides login continuity with one service, trade
continuity inside one room, private history continuity on the user's own
machine, and optional evidence disclosure to a chosen counterparty — without
producing a public transaction graph, a lifelong identifier, or a scalar
trust score.

It does not produce Sybil resistance. That limitation is stated explicitly
rather than obscured, and the one mechanism that could partially address it is
described as a bounded, honest option rather than a solution.

---

## 1. Background: the system this applies to

The mediator coordinates trades but never holds, inspects, verifies, or
broadcasts value. Each published offer is also a waiting lobby recording only
the asset and integer amount the creator sells, the asset and amount it buys,
a number of fractional settlement rounds, and an opaque receive address. A
second party takes the offer by room ID and supplies its own address. The room
becomes an active settlement session.

Transfers happen externally, on whatever chains the two assets live on. The
mediator coordinates only `sent` and `received` acknowledgements. It does not
identify the chain, validate address format, or confirm that anything moved.

Two properties of this design shape everything that follows.

**Acknowledgements are claims, not proofs.** When a party signals `sent`, the
mediator learns that a message arrived, nothing more. A completed room means
two parties clicked through a state machine. It does not mean value changed
hands.

**Fractional rounds cap damage, they do not deter.** Splitting a trade into *N*
tranches with alternating legs means a defector who abandons the trade at the
last leg steals at most `total/N`. This is real protection against catastrophic
loss. It is not deterrence, because the cost of acquiring a fresh identity and
finding another counterparty is approximately zero. An attacker farms `total/N`
from many victims indefinitely.

The transport, by contrast, is deliberately hardened against correlation. TLS
1.3 only, session tickets disabled on both the option and ticket-count paths
specifically so resumption cannot link sessions, no client authentication, no
accounts, fixed-size framing with a hard payload cap, and optional SOCKS5
transport for onion endpoints.

That last point is the crux. **The codebase already treats cross-session
linkability as an attack.** A reputation system that publishes a stable key in
the offer book would not be a mild weakening of that stance — it would invert
it, handing every observer a permanent identifier that TLS resumption was
disabled to prevent.

---

## 2. Design constraints

1. **No public lifelong identifier.** Nothing the architecture introduces may
   become a stable handle visible across trades to the offer book, other
   clients, or a mediator the user did not choose.
2. **No scalar score.** Reputation collapses information. Structured evidence
   preserves the reader's ability to judge.
3. **No claim of Sybil resistance.** Key continuity proves continuity. It does
   not prove unique personhood, and the architecture must not imply otherwise
   anywhere in code, documentation, or interface.
4. **No gossip.** Personal judgements about counterparties never leave the
   user's machine unless explicitly exported.
5. **Optional in practice, not just in principle.** A design where opting in
   costs unlinkability is not optional; it is compulsory with extra steps
   (§10.3).
6. **Honest layering.** Evidence a user generated about themselves and evidence
   a third party attested to are different objects with different weight, and
   must never be represented as interchangeable.

### Non-goals

Identity verification. Dispute arbitration. Custody or escrow. Transaction
verification. Global blocklists. Any mechanism requiring the mediator to be
trusted with value or with truth about the chains.

---

## 3. Threat model

**The mediator is not trusted.** It may be adversarial, may be run by a
counterparty, may collude, may forge, and — because node registration is
currently unauthenticated — may be cheap to become at scale. Every claim a
mediator makes must be independently checkable or explicitly marked as
mediator-asserted.

**Counterparties are not trusted.** They may defect at the final leg, withhold
receipts to deny an honest counterparty credit, farm reputation against
themselves through self-trades, or attempt to correlate a user's activity
across trades.

**Observers of the offer book are not trusted.** Anything published is
published to an adversary building a correlation graph.

**The user's machine is trusted, conditionally.** Local storage is assumed
private but not durable — crash, corruption, rollback, and loss are expected
and must fail loudly rather than silently.

**Explicitly outside the model:** chain analysis of settled transactions
(§10.1), traffic-timing correlation by a mediator observing both connections
(§10.2), and endpoint compromise.

---

## 4. Key architecture

A single master secret, never transmitted, from which scoped keys are derived:

```
master identity secret
├── service-scoped login key        one per service
├── local-history authentication key  one, never leaves the machine
├── per-mediator pseudonym key      one per mediator
└── per-trade ephemeral key         one per room, randomly generated
```

Long-term scoped keys are derived deterministically via HKDF-SHA256, with the
master secret as input keying material and a **length-prefixed, domain-labelled
context structure** as the `info` parameter. Naive concatenation is prohibited:
`"login" ‖ "x"` and `"logi" ‖ "nx"` produce identical bytes, and an ambiguity
in derivation is as dangerous as an ambiguity in a signed message. Derived
32-byte outputs become Ed25519 keys directly.

The per-trade key is the exception: it is **freshly generated at random and
never derived**. Derivation from the master secret would make trade keys
mutually linkable to anyone who later learned the derivation path, defeating
the purpose. This has an operational consequence — a randomly generated key
cannot be regenerated after a crash, so the ephemeral key for any in-flight
room must be persisted alongside journal state.

### Why per-mediator pseudonyms

A user who returns to the same mediator repeatedly presents the same pseudonym
there and can accumulate standing. That mediator learns nothing about the
user's activity elsewhere, because a different mediator sees an unrelated key.
An adversary running many mediators to correlate a user gets many unlinkable
pseudonyms — the attack does not scale.

The mediator identifier used in derivation should be a durable identity rather
than a certificate fingerprint, or key rotation silently destroys accumulated
standing.

---

## 5. Layer one — the local journal

An encrypted, hash-chained, append-only record maintained by each client of its
own activity. Each entry commits to the room and trade identifiers, mediator
identity, counterparty pseudonym fingerprint, a commitment to terms, round
number, message direction and type, a hash of the message, acknowledgement
state, local settlement state, timestamp, and the previous entry's hash:

```
entry_hash[n] = H( canonical_entry[n] ‖ entry_hash[n-1] )
```

Checkpoints are authenticated with the local-history key. The chain detects
modification, deletion of interior entries, reordering, rollback to an earlier
checkpoint, and malformed state transitions.

**What it is for:** crash and reconnect recovery, duplicate-action prevention,
corruption detection, and feeding the private counterparty record.

**What it is not:** evidence. The journal proves what the local client
recorded. A user can write anything into their own journal. It has no value to
a counterparty and must never be presented as though it does. This distinction
is the most important boundary in the architecture and the easiest to erode.

The journal never publishes anything automatically.

### Recovery and the persistence trade-off

A client journal alone cannot resurrect a half-settled room, because the
authoritative multi-party state — whose turn it is, what both sides have
acknowledged — lives on the mediator. Recovery therefore requires mediator-side
room persistence.

This is a genuine cost, not a free improvement. Memory-only mediator state is
*accidentally* a privacy property: a seized or compromised mediator has nothing
on disk about past rooms. Durable room state means durably storing the pair of
receive addresses that links two counterparties — exactly the linkage the
architecture exists to prevent.

The trade-off must be made explicitly. Options, in rough order of preference:
persist the state machine but not addresses, re-soliciting them from clients on
recovery; encrypt room state at rest under an operator-held key; delete
aggressively on completion. Accepting the exposure silently is not an option.

---

## 6. Layer two — mediator-signed staged receipts

A receipt is an attestation signed by a party other than its holder. Unlike the
journal, it carries weight to a third party.

A receipt binds: version, room identifier or privacy-preserving room
commitment, terms commitment, the parties' ephemeral public keys or scoped
pseudonyms, mediator public key, stage, completion state, timestamp, unique
nonce, and the hash of the previous stage's receipt.

A bare assertion of the form *"key X traded successfully"* is prohibited. Such
a statement is replayable into any context and attests to nothing checkable.

### Staging

```
1. terms accepted
2. round N acknowledged
3. all obligations except final settlement completed
4. settlement completed
```

Each stage commits to the hash of the previous, so a later receipt without a
valid predecessor is rejected. A completion receipt may only be issued once the
protocol's actual completion condition holds.

Where practical, receipts use two-party acknowledgement plus mediator
countersignature rather than a mediator-only assertion, so that a hostile
mediator cannot unilaterally fabricate an attestation neither party made.

### The withholding problem

Staging alone is insufficient. If receipts are issued *after* a round
completes, a defector simply declines to participate in the final receipt
exchange. The honest party is left with nothing recorded for a trade they
completed in good faith, and withholding costs the withholder nothing. Griefing
is free, and reputation accrual becomes something a counterparty can veto after
the fact.

The fix is timing, not structure. **The stage-3 receipt is a required
settlement step that occurs before the final tranche is sent.** Withholding it
therefore also withholds the withholder's own last leg. The cost of griefing
becomes the value of one tranche, which is precisely the cost of defection —
withholding stops being a free action and becomes just another form of
abandonment, already handled by the fractional model.

This invariant is subtle and will regress silently if it is not covered by an
explicit test that simulates refusal and asserts the protocol-level
consequence.

---

## 7. Layer three — selective disclosure

Receipts are private by default. There is no publication path, no aggregation,
no directory.

A holder may disclose specific receipts to a specific counterparty during a
specific negotiation. Disclosures are bound to the intended recipient and are
not broadcastable — a receipt shown to one party cannot be replayed by an
interceptor as their own.

Linkage is thereby **scoped to whoever the holder chose to show, for the
duration of one negotiation**, rather than global and permanent. This is the
architecture's central move: reputation that exists without a public graph.

Selective disclosure is fully implementable with primitives already available.
It is the realistic near-term deliverable.

---

## 8. Layer four — unlinkable aggregate credentials

Selective disclosure has a residual leak: the receipts a holder shows are
individually identifiable, so a counterparty who is also a mediator, or who
compares notes with one, can correlate them.

The mitigation is blind-signed completion tokens. The mediator signs a token
per completed room without seeing which token it signed. The holder later
proves possession of *N* tokens without revealing which rooms produced them.

**Implementation reality.** Naive blind Schnorr over Ed25519 is unsafe under
concurrent signing sessions — the ROS attack makes parallel sessions forgeable.
RSA blind signatures (RFC 9474) are the sound and practically available choice,
implementable with the existing OpenSSL dependency at the cost of larger
tokens. BBS+ would additionally permit disclosing attributes such as volume or
age bands without revealing underlying receipts, but requires pairing-friendly
curve support that this dependency set does not contain. BBS+ is therefore
future work, and the receipt serialization is versioned so that an anonymous
credential layer is an additive version rather than a replacement.

Blind tokens address **linkability only**. They contribute nothing to Sybil
resistance and must not be presented as though they do.

---

## 9. Sybil resistance, and why this architecture does not achieve it

Keys are free. Two identities created in a second can complete a hundred rooms
with each other, moving no value, and mint a spotless mutual history. Because
acknowledgements are unverified claims (§1), a reputation built on completed
rooms is a reputation about **claim-making**, not behavior — and claim-making
costs nothing.

No cryptographic mechanism fixes this. Unforgeable, unlinkable, perfectly
staged receipts attesting to a hundred fake trades are unforgeable, unlinkable,
perfectly staged garbage. **The signature is sound; the referent is fiction.**

Approaches considered and rejected:

- **Proof of work** — a one-time amortizable tax. An attacker pays once and
  farms indefinitely.
- **Social vouching** — imports a social graph, which is a deanonymization
  surface, directly contradicting the design's purpose.
- **Mediator attestation of value movement** — the mediator cannot see the
  chains. This is the founding constraint, not an implementation gap.

### Bond anchoring: a bounded, honest partial measure

A reputation key may publish a bond address. Reputation weight is a function of
value visibly at risk in that address multiplied by the age of the bond.
Verification is a balance check performed by the client, which keeps the
mediator out of the trust computation and keeps the design chain-agnostic.

What this achieves: a fresh keypair cannot fake accumulated sunk cost, and cost
scales linearly with the number of identities, so farming stops being free.

What it does not achieve: without smart contracts there is no slashing. A bond
is a demonstration of stake, not a forfeitable deposit. It raises the cost of
Sybil attacks; it does not prevent them. It also introduces a chain-visible
artifact, which is a linkability cost that must be weighed against the Sybil
benefit — and for many users that trade will not be worth making.

Bond anchoring is offered as an option with its costs stated, not as a
solution.

---

## 10. What this architecture does not do

### 10.1 It does not make trading anonymous

The cryptography does what it claims. Blind signatures are unlinkable; scoped
keys do not correlate across mediators. But those guarantees cover **the
contents of protocol messages**, and very little else about the situation.

Trades settle on public chains. The addresses exchanged at room formation are
the linkage, and chain analysis is indifferent to how elegantly they were
exchanged. Protocol-level unlinkability is upstream of the part where value
actually moves.

The accurate claim is narrow: *this removes identity from the protocol's
reputation mechanism.* It does not remove identity from the act of trading.

The reason the work is still worth doing is defensive rather than aspirational.
A naive public reputation key would **manufacture** a new, permanent,
cross-trade identifier that an observer did not previously have — on top of
everything already inferable. Declining to create that is a real gain. It is
not anonymity.

### 10.2 It does not hide anything from the mediator

Ephemeral trade keys prevent correlation by other clients and by observers of
the offer book. The mediator sees which connection joined which room in real
time regardless of what key signs the messages inside it. Onion routing hides
network location, not session timing. Round-by-round acknowledgement produces a
distinctive traffic rhythm on a channel with fixed framing and a small payload
cap.

Any documentation implying that ephemeral keys conceal activity from the
mediator is overselling, and the wording is the bug.

### 10.3 "Optional" is unstable

Once some offers carry reputation signals, unkeyed offers are deprioritized in
practice, and the anonymity set collapses toward "participants with something
to hide." Optionality that is nominal rather than real is worse than no
optionality, because it produces a stigmatized minority while claiming
neutrality.

The blind-credential route (§8) is the only variant where opting in does not
cost unlinkability, and is therefore the only one where the two populations
plausibly stay mixed. Any implementation that ends up requiring a persistent,
always-visible identifier to participate in reputation at all is a regression
against this framing and should be treated as a defect.

### 10.4 It does not survive a hostile hosted client

A browser page cannot protect a private key from an operator who controls the
JavaScript it serves. Key-based login in a hosted client protects against
stored-credential compromise — leaked account databases, credential stuffing —
and against nothing else. Native clients, external signers, or WebAuthn are the
only paths where browser-context key handling means more than that.

### 10.5 Key loss is total

There is no recovery authority, by construction. A lost keystore is a lost
identity and a reset to zero standing. This is not a flaw to be engineered
around; it is the Sybil cost surfacing honestly. Encrypted backup and export
paths are required; a recovery service is not possible without reintroducing a
trusted party.

---

## 11. Presentation: structured evidence, not a score

Clients present, separately and without aggregation:

```
key age
receipt count
distinct mediator count
economic cost / bond age / bond value band
prior interaction with this specific client
locally blocked status
```

These must not collapse into a single number. A scalar invites the reader to
stop thinking; separate axes let them weigh what matters for the trade in front
of them. A counterparty with two receipts from a mediator you trust is not
comparable to one with fifty from mediators you have never seen, and no
weighting function should be permitted to decide that on the user's behalf.

A key confers no status. In any interface, possession of a key means exactly:

> This participant has demonstrated control of the same scoped key.

It does not mean trusted, verified, human, safe, or economically reputable. A
key badge presented as a trust indicator is a design failure, because it
communicates a Sybil-resistance property the system does not have.

Correspondingly, keyed participants are never ranked above unkeyed ones by
default. This is client-side policy and unenforceable at the protocol level —
a forked client may ignore it — and should be documented as an intention
rather than a guarantee.

---

## 12. Deployment sequence

Ordered by value delivered and hard dependency, not by conceptual layering.

| Stage | Content | Rationale |
|---|---|---|
| 1 | Crypto primitives | Everything depends on it |
| 2 | Encrypted local keystore | Nothing can store a key without it |
| 3 | Journal, recovery, mediator persistence | Fixes a live state-loss risk independent of identity; requires the §5 privacy decision |
| 4 | Local counterparty history | Nearly free once 2–3 exist; immediate user value |
| 5 | Per-trade ephemeral identities | Receipts must bind to these, not to a long-term key |
| 6 | Staged receipts | Depends on 5; requires the §6 withholding timing |
| 7 | Service-scoped login | Lowest value; replaces stored passwords only |
| 8 | Selective disclosure | Depends on 6 |
| 9 | Hosted client integration | Touches the most surface; depends on everything |

Two dependencies fall outside this sequence and gate parts of it. Node
registration is currently unauthenticated, and a keyed reputation system makes
running a hostile mediator more profitable — that fix belongs before or
alongside stage 6, since receipts are the first artifact a hostile mediator
gains from forging. Separately, connection admission control gates stage 7,
which adds pre-session cryptographic work to a path that currently has none.

---

## 13. Summary

The architecture provides:

- login continuity with one service
- trade continuity inside one room
- private history continuity on the user's own machine
- optional evidence disclosure to a chosen counterparty

It deliberately does not provide:

- one public lifelong identifier
- a public transaction graph
- a Sybil-resistant reputation score
- automatic global blocklists
- a mandatory reputation class system

The central claim is modest and, stated plainly, defensible: reputation can be
made to exist without a public graph, and evidence can be made to carry weight
without becoming a permanent handle. The central limitation is equally plain:
in a system where settlement is unverified and identity is free, no reputation
mechanism distinguishes an honest participant from a patient one. Fractional
settlement caps the damage. Nothing here removes it.

Designs that claim otherwise are describing a system that verifies value
movement. This one does not, and says so.