Insights30 مايو 20268 min read

Marketplaces ship features. Trust marketplaces ship rules.

How we designed CredoGrid's escrow handshake — and why publishing the dispute rule on day one is the trust mechanism, not the feature roadmap.

Two outstretched hands meeting over a small glowing lockbox marked with a credit symbol — a third hand, ghosted, hovering at the side as the arbiter.

Marketplaces live or die on what happens when something goes wrong. Most ship features — better filters, better profiles, better notifications. Trust marketplaces ship rules. Here's what we learned building CredoGrid's escrow handshake, and why the dispute rule had to be the first thing we wrote down.

I used to think marketplaces were a UX problem. Build the right surfaces, write the right copy, get the onboarding right, and the market clears. Two-sided liquidity, smooth handshakes, magic.

Building CredoGrid taught me marketplaces are a rules problem. The UX is plumbing. The actual product is the answer to the question: what happens when the connector says they delivered the intro and the requester says they didn't.

Every marketplace eventually has to answer that. Most answer it badly, in DMs, after the fact, with a customer-success team interpreting facts they can't verify. CredoGrid is a B2B intro marketplace where credits move through dual-party escrow — we had to answer it on day one, in the product, before anybody had hit the case.

Escrow as the only honest handshake

The mechanic we settled on is a two-party lockbox. A requester spends credits to ask for an intro. The credits don't go to the connector — they lock in escrow. They release to the connector only when both parties confirm the intro actually landed.

Either side can mark the connection as failed. An unanswered confirmation auto-refunds after a configured window. There's no scenario where a connector pockets credits for an intro that didn't happen and no scenario where a requester ghosts a successful intro and keeps the credits.

The data model that makes this work is unfussy and important. The credit ledger is append-only. Locks, releases, refunds are all entries, never updates. The current escrow state for a request is derived from the entries, not stored as a mutable field. This isn't a fintech-grade requirement; it's a clarity requirement. The moment you mutate a balance in place, you've lost the ability to answer the question "when exactly did this state change."

The dispute split as written law

Here's the rule we shipped: when parties disagree on whether the intro landed, the requester's assessment wins by default, and 75% of the escrow transfers.

Three things matter about that sentence. First, it's specific. Not "we'll review." A specific split. Second, it favors the requester. Not because requesters are saints — because requesters bear the asymmetric cost of an unhonored ask. Third, it's published on the rules page, not buried in the TOS. Every user can read it before they spend a credit.

Predictability is the trust mechanism. The first time we explained this to a skeptical pilot user, she said "so if my connector ghosts me I get 75% back." Yes. "And if he claims he did it and I disagree, I get 75% back." Yes. "And if he disagrees in good faith, the system still defaults to me." Yes. She thought about it for a second and said: "that's fair enough to use." That single sentence was the entire trust signal. Specific rules are the bar — vague rules read as discretion, and discretion in a marketplace is suspicion.

A diagram showing the lifecycle of a single intro request — credits leave the requester wallet, enter escrow, and either release to the connector on dual confirmation or refund 75% to the requester on dispute.
Append-only ledger. Three possible terminal states. No discretion.

Credibility has shape, not a number

We launched with a single 0–5 score for connector credibility. Users hated it within a week. The number was easy to game and hard to act on. "This person is a 4.2" doesn't tell you whether they reply fast, complete what they accept, or only show up when the request is in their narrow vertical.

We rebuilt it as a credibility profile — response time, completion rate, dispute history, average request quality — shown separately. The single score still exists internally for ranking, but the public surface is the shape. Other users see how you're reliable, not just that you are.

The lesson generalizes. Any time you reduce a multi-dimensional reputation to a single number, you've given users the same affordance as a credit score and the same temptation as Goodhart's Law. Shape is harder to game and easier to read.

Vague rules read as discretion. Discretion in a marketplace is suspicion.

On dispute resolution

What we'd start with on day one

Three things. Append-only ledger from minute one — no mutable balances even in the MVP. Published dispute rule with a specific split before the first user signs up — even if no dispute has happened. Multi-dimensional credibility shape from the start, never a flat 0–5.

Everything else is plumbing. Two-sided liquidity, onboarding, notifications, search. Those are real and they matter. They're not the product. The rule is the product.

The rule is the product. The features are how you ship it.

CredoGrid is a Synara product. We're happy to scope an escrow-mediated two-sided marketplace — intro brokerage, services exchange, gig settlement, anything where neither party will move first — using the same primitives.