You post the task with the place, the deadline, the price and the proof you want (photos, video, a receipt, a location check). People nearby make offers, and you pick one based on their public profile, ratings and reviews. The payment waits in escrow and is released when the proof arrives and you approve it.

It's live on Base mainnet with real USDC. Posting is free. It's also pre-revenue and early, so this post isn't a launch announcement. It's a write-up of the design, because I'd like people who know this space to poke holes in it.

The problem: paying a stranger who is far away

The hard part of this product isn't matching. It's trust. If I'm in Istanbul and need someone in Lisbon to look at a flat, neither of us wants to go first. I don't want to pay before I see anything, and they don't want to do the work and then hope I pay.

The usual answer is that the platform holds the money. I wanted it somewhere both sides can check, under rules nobody (including me) can quietly change. So payments go into a public smart contract on Base, in Circle's native USDC.

Signed terms, funded by the requester

Each deal's terms (price, fee rate, milestones, deadlines, review period, grace period, dispute timeout) are signed by the platform's deal signer as EIP-712 typed data. The requester then funds the escrow against those signed terms. Hard bounds for what can be signed are constants in the contract.

Splitting it this way means the platform decides what a valid deal looks like, but the deal signer can't move money. The requester signs and funds every escrow. The signer is a dedicated key held in AWS KMS, separate from the admin role.

Funding is one transaction: a multicall that wraps a USDC permit (selfPermit) and the create/propose/accept call. One detail I had to deal with: if someone front-runs the permit and submits it first, funding still has to work as long as the allowance is in place. So selfPermit tolerates a permit that has already been used.

Pull payments, not push

The contract never sends USDC to a user in the middle of a settlement. When a milestone settles, it credits an internal balance: owed[token][account]. Funds leave the contract only through withdrawFor / withdrawForMany, which always pay that account, or through sweepExcess, which can only move surplus above all liabilities to the treasury.

Why bother:

• Settlement logic stays simple. Approving, claiming, refunding and resolving disputes are all just accounting. No external token call happens in the middle of a state change.
• A blocked transfer doesn't break a deal. USDC has an issuer blocklist. If a transfer to one address fails, the deal still settles and the credit simply stays owed.
• Payouts can be batched and sponsored. Because withdrawFor is permissionless and can only pay the rightful owner, a platform relayer can call it for users. That relayer is a hot wallet that holds only gas, and the contract treats it as untrusted for funds.

The rules I wrote down for the contract and test against include: total liabilities equal the sum of owed credits plus locked amounts; the contract's balance always covers them; each milestone settles exactly once; and money only ever goes to the stored requester, the helper or the treasury.

The deal lifecycle

In short:

1. The requester funds a listing. For a fixed-price request that happens at publish. For one open to offers, it happens when they choose an offer.
2. The helper accepts the exact proposal (by nonce).
3. The helper submits work. The requester approves, asks for a revision, or disputes.
4. If the requester goes silent, the helper can claim after the review window. On the site that's 1 or 2 days.
5. If nothing was submitted by the deadline plus a grace period, the requester can reclaim what hasn't been paid. Submission is allowed up to deadline + grace, inclusive, and reclaim starts strictly after, so the two windows never overlap.

Deals can have multiple milestones, and a milestone that's been paid stays paid.

The contract is non-upgradeable. That cuts both ways. Nobody, including me, can swap the logic under a live deal. But if I missed something, I can't patch it in place. It's why I've spent more time on specs and tests than on UI.

Pausing is deliberately one-sided. It blocks new commitments (create, propose, accept, additions) but never blocks an exit, a settlement or a payout. If something goes wrong, I can stop new money coming in without trapping the money already there.

Disputes: a trusted reviewer, on purpose

This is the part I expect the most pushback on. Disputes are decided by a neutral reviewer, and the arbitrator role is a 2-of-2 Safe, so every ruling needs two signatures. That's a trusted arbitrator, not a decentralised court.

I considered token-voting and juror-style schemes, but for a $40 store check they add cost, delay and complexity. Instead I tried to limit how much depends on the arbitrator:

• Mutual split first. Either side can offer a split of the current milestone, and the other accepts the exact terms. No dispute fee, and it works even during a dispute.
• Narrow dispute windows. The requester can dispute a submission only within its review window. Either party can dispute work in progress until deadline + grace.
• A timeout default. If no ruling arrives within the signed dispute timeout, anyone can apply the default. A standing submission is paid as claimed, and without one the milestone is refunded. Funds can't sit frozen forever because a reviewer went quiet.

Evidence lives off-chain: every message and file in a deal is kept, and proof photos can include challenge codes so they can't just be reused from somewhere else.

Passkey wallets and sponsored gas

Most people who need an apartment viewed don't own crypto, and shouldn't have to. So:

• A wallet is created at sign-up and protected by a passkey: Face ID, a fingerprint or the device PIN. No seed phrase. I don't hold users' keys, and the private key can be exported.
• You can add USDC with a card or send it from crypto you already hold.
• Network fees are covered by the platform. Users never need ETH.

The pull-payment design is what makes sponsoring the payout side cheap and safe. A relayer that only holds gas can call payouts for anyone without being able to redirect a cent.

Fees and limits

The requester pays exactly the agreed price. The 10% platform fee comes out of the helper's side only. When a task includes an item budget (buying something on the requester's behalf), the fee applies only to the reward part, not the item cost. Deals start at $5. New accounts can go up to $200 per deal, and trusted accounts up to $2,000.

Honest limitations

• It's early. Whether a task gets picked up depends on who happens to be nearby.
• A visit from a stranger is not a professional inspection.
• The arbitrator is trusted, as described above.
• The contract is non-upgradeable, so any bug in it stays there. Please treat this as early software.

Feedback wanted

If you work on escrow, account abstraction or dispute design, I'd really like to hear where you think this breaks. And if you'd like to earn USDC doing short tasks where you live, you can sign up as a helper.

• Site: ineedsome.one (how it works: /faq)
• Escrow contract on Base: 0x4C0CcF43144392B831C46cb68E8e80f76304BCbC
• Contact: support@ineedsome.one