PragueConnect
Hire by name. Pay in private. Keep the reputation
About
The problem it 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.
How it's made
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.