Designing a Trust Model for Local Peer-to-Peer Transactions

Context

Anyone who has used a local classifieds marketplace knows the moment: cash in hand, a stranger across from you, an item you can only briefly inspect, and nothing protecting either side of the exchange. I had been on the wrong end of that arrangement more than once, and researching the problem made clear it wasn’t bad luck: marketplace fraud, phishing, fake payments, robberies at meetups, counterfeit goods, and identity abuse were widespread enough in Canada to justify exploring a different transaction model. I stopped treating those experiences as accidents and started treating them as a design problem.

From February 2023 through May 2025 I worked on Eskro, a local peer-to-peer marketplace built to answer that problem with a different allocation of responsibility: the transaction process, not the individuals, carries the trust. I owned the product side through 2023 and 2024: product discovery, workflow design, the trust and access model, the transaction lifecycle, marketplace policies, the KYC (identity-verification) and warranty models, and dispute handling. I stayed on the product through implementation, testing, and beta refinement in 2024 and 2025, where engineering was collaborative with the development team. The operational decisions documented here are mine; this case study describes the reasoning behind them.

Problem & stakes

The trust problem in local P2P commerce is structural, not behavioural:

• The parties are anonymous, both to each other and to any system that could hold them accountable.
• Payment and trust arrive at the same instant, with no recourse after the handshake.
• Nothing records what happened. When a deal goes bad there is no state, no evidence, and no process. Only two contradictory stories.

The category had largely accepted this as the price of simplicity. The design question was whether operational design could remove the avoidable risk while keeping what makes local P2P work: meeting in person, seeing the item, simple exchanges.

The thesis, and what the platform actually promises

The core thesis: the responsibility for trust should shift from the individual to the platform. The boundary that makes that thesis honest came through failure (told below), and became the governing principle: the platform guarantees the integrity of the transaction process, not the perfection of every transaction outcome.

That boundary is communicated as an explicit promise contract rather than marketing reassurance. Eskro does not promise perfect outcomes, perfect sellers, authentic products, or buyer satisfaction. It promises verified participant identities, transparent workflows, observable transaction states, documented evidence, consistent operational rules, and structured dispute handling. The buyer remains responsible for judging value and acceptability. The platform verifies the integrity of the transaction, not the desirability of the goods. Designing the promise as a bounded list was itself a product decision: a platform that overpromises trust recreates, at dispute time, exactly the disappointment it was built to remove.

Where trust enters

Trust-based access follows one rule: trust is introduced exactly when a user begins to affect other users. Browsing is unrestricted, because discovery costs nothing. Messaging a seller, publishing a listing, and transacting all require verified identity. The rejected alternative was the category norm, anonymous participation with verification bolted on at payment time, and the rejection had a stated objective: accountability rather than anonymous supply. The trade is friction at first contact. The design places that cost up front, where it buys accountability, rather than downstream in a dispute queue.

Trust also never becomes a privilege. A history of successful transactions improves confidence, but it never eliminates verification: every transaction is independently protected. Reputation-unlocked shortcuts were the obvious alternative; they reintroduce the assumption problem with a delay.

The transaction lifecycle

The lifecycle is a state machine in which every critical state is created by an observable event: identity verified, payment authorized, meeting confirmed, inspection started, accepted, warranty, payout. Memory and claims are not state.

A transaction runs like this. The buyer authorizes payment, which is commitment, not completion. The platform holds settlement. The parties meet in person, and the meeting is confirmed by a QR scan, designed not as authentication but as the creation of a trusted transaction state: it timestamps that the meeting occurred, starts the inspection window, and activates the release, return, and dispute logic downstream. From that scan, the buyer has a bounded inspection window of thirty minutes to accept the item or reject it and initiate the return workflow. If the buyer does nothing, the transaction progresses automatically: acceptance is recorded and the warranty period begins. The window is deliberately category-flat. The objective was never to optimize inspection time per item type, but to give every transaction a predictable, operationally consistent acceptance window balancing buyer inspection against seller certainty. The exact duration was an implementation parameter; the governing principle is that acceptance is bounded rather than indefinite. And the seller is paid only after the warranty period expires. “Release” at acceptance changes the transaction’s state, not the location of the money, which is what keeps a warranty reversal a clean settlement operation instead of a clawback from funds a seller may already have spent.

Each stage of that machine is a decision with a rejected alternative, and the rejections are where the design’s judgment is most visible.

The refusals

Two of these refusals only work because of a supporting decision. Refusing item authentication functions because the listing is evidence, not marketing. Mandatory structured fields where applicable (photos, condition, description, defects, accessories, functionality, serial number) make the seller’s own representation the evidentiary baseline. The buyer compares the physical item against what the seller claimed; disputes adjudicate listing-versus-item, never quality-in-the-abstract. And refusing insurance functions because of the deferred payout above. A successful warranty claim reverses a settlement the platform still orchestrates: the buyer returns the item and receives the held funds, and the seller receives the item back. Eskro never pays a claim. It unwinds an exchange.

When transactions go wrong

Dispute handling follows one operational rule: the party requesting a change to the current transaction state carries the burden of providing sufficient evidence. When evidence clearly supports one side, the platform rules accordingly. When evidence is insufficient to justify changing the existing state, the current state remains. Evidence is compared against the seller’s original listing and the transaction’s recorded history. This is why the listing fields and the observable state machine exist: they are what disputes are adjudicated from.

This is a deliberate choice of procedural fairness over substantive fairness, and it is worth stating plainly: a party who is factually right but cannot evidence it will lose, through a process that ran with complete integrity. The alternative models (default-to-buyer, default-to-seller, or agent discretion case by case) each fail worse. The first two pick a permanent winner in advance, and the third reproduces exactly the inconsistency that bounded liability exists to prevent.

The design also has known open edges, documented rather than hidden, in evidence capture, exception handling, and dispute routing. The refinement queue of a trust system is real, and acknowledging it is part of operating one.

What the design got wrong first

Three assumptions failed under design scrutiny, all three at the design table before any reached a live transaction, and each failure became structure.

“Acceptance will always be explicit.” The original lifecycle assumed every buyer would affirmatively accept or reject. Walking the state machine as an adversary surfaced the failure mode: a buyer who simply disappears after receiving the item, holding settlement hostage indefinitely with no consequence and no recourse for the seller. The fix is the bounded inspection window with automatic progression: a deliberate trade of perfect certainty for operational scalability, and the one place the design knowingly treats the absence of an event as a decision.

“A platform can eliminate scams.” The original goal, and the deepest failure. No operational design eliminates dishonesty. What design can do is remove the avoidable risk (anonymity, unrecorded state, payment without recourse) and be explicit about what remains. Demoted from goal to boundary, the realization became the parent principle everything above derives from.

“Maybe the platform should authenticate items.” Genuinely explored, since it is the natural next promise after identity verification, and deliberately rejected for the reasons recorded above. The rejection fixed the platform’s operational boundary; listing-as-evidence made it workable.

What held, and what it cost

Stated at the level the work supports, and deliberately conservative: no production adoption, commercial outcomes, or operational KPIs are claimed.

• The model was implemented and carried through testing and beta refinement with the development team across 2024–2025, with the operational rules holding their shape from design into live use.
• The philosophy held under design pressure. Late decisions like deferred payout, burden-of-proof disputes, and the promise contract derive from the parent principle rather than patching around it. The system’s answers became more consistent as it grew, not less.
• The costs were taken knowingly: verification friction at first contact, seller payout latency through the warranty window, and a bounded acceptance window that treats silence as progression. Each is a stated price, for accountability, clean reversals, and bounded exposure respectively.

After the beta phase and continued product refinement, my active involvement with Eskro concluded in May 2025. The beta validated the operational model this case study documents: the trust framework, transaction lifecycle, escrow workflow, dispute process, and marketplace policies. The work remains one of the strongest examples of my product thinking and operational design.

What I’d do differently

• Capture more evidence at key transaction points, earlier, while preserving the operational simplicity the platform is built on.
• Design degraded-mode workflows earlier, so connectivity failures and exceptional situations are intentionally handled rather than documented after the fact.
• Give fraud-adjacent reports their own operational path, distinct from routine condition disputes, because they require different operational handling.
• Make seller responsibilities and buyer expectations even more explicit before transactions begin, so operational boundaries are understood before disputes ever occur rather than discovered inside one.

None of these change the underlying philosophy. They strengthen the operational execution of it.

Transferable lessons

• The four refusals shaped the system more than any feature did. Each one converted a promise the platform could not keep consistently into one it could, and the parent principle is just the four of them, generalized.
• Every dispute the design resolves cleanly traces back to an observable event; every open edge it still has traces to a moment where state wasn’t captured. That correlation, discovered repeatedly, is the clearest pattern the design produced.
• The explicit promise contract was designed so that no user would discover the platform’s limits for the first time inside a dispute. It costs reassurance up front and repays it at the moment trust is actually tested.
• The most concrete of the three failures, the disappearing buyer, was caught by walking the lifecycle as an adversary: asking, at each state, who could abuse it, who could disappear from it, and what the platform had promised about it.