The problem PragueConnect solves

Today, getting your bike fixed by a neighbor in Prague usually goes
through Facebook Marketplace, a Telegram group, or a private WhatsApp
chain. All of them put your real name + phone + home area next to a
public ad. PragueConnect uses an ENS name as your identity —
kilian.pragueconnect.eth is enough to receive payments, open sealed
conversations over XMTP, and accumulate reviews. Nobody needs your
phone, your bank, or your address.

"I have to pick: trust the buyer to pay after delivery, or trust the seller to deliver

after payment"

Cash deals between strangers force one side to carry all the risk.
PragueConnect's escrow contract holds funds on Base while the work
happens, and releases when the buyer signs off — or after a 24h grace
period if the buyer ghosts. Both sides see the on-chain phase change
live. The buyer's funds are safe, the worker is guaranteed paid,
nobody is the custodian in the middle.

"Every payment I make leaks who paid whom for what"

Standard on-chain payments are public — anyone can pull up your
address and see who you tipped, when, and for what. PragueConnect
resolves names to a fresh stealth address every time anyone asks.
Send 500 Kč to alice.pragueconnect.eth from MetaMask; refresh, send
another 500 Kč; the two payments land at different addresses, and
only Alice can see which ones are hers. Bank-statement-grade privacy
without a bank.

"If I use a platform like TaskRabbit, I lose my reputation when I lose my account"

PragueConnect isn't a platform — it's a self-hostable resolver,
gateway, and set of contracts. Your reputation lives in your ENS
name's records, sealed by you, queryable by anyone, portable to any
service that resolves ENS. If we go offline tomorrow, your name
still works. Your reviews still resolve. Your sealed payment route
still receives.

Challenges we ran into

The hard problem: privacy that actually holds on a public chain

PragueConnect's whole thesis is a marketplace where identity, payments,
and work history don't leak. The hard part — the thing that ate most of
the build week — is that "doesn't leak" on a public ledger is a much
higher bar than it sounds. Every layer that looks private has a seam
where information escapes. The build was, in honest terms, a continuous
audit of those seams: finding them, sealing the ones we could, and
naming the ones we couldn't.

Leak we found and sealed: the escrow that wasn't actually private

The v1 escrow contract used require(msg.sender == t.worker) on
accept, deliver, and release. Release paid out to a stealth address
and emitted an ERC-5564 announcement, so it looked like a
privacy-preserving payment flow.

The bug — caught mid-conversation while explaining the architecture —
was that the worker's main EOA had to be msg.sender of three
transactions per task. The accept tx alone publicly bound the worker's
EOA to the stealth recipient in one move:

worker_eoa published 0xSTEALTH in task T
escrow paid 0xSTEALTH in task T
∴ worker_eoa owns 0xSTEALTH

The "stealth payout" was theatre. We rewrote the contract to drop
msg.sender-based auth entirely. V2 uses EIP-712 signatures from
the worker's stealth spending key; ecrecover verifies the signer
against the address committed at fund time. Anyone can submit the tx
(funder, a hosted relayer, the worker from any address); the worker's
main EOA never appears in any task event. Live on Base at
0xE2571571…20A5a with twelve Foundry tests, one of which explicitly
asserts no main address ever shows up as msg.sender in any escrow
event.