A peer-to-peer delivery looks simple from the outside: someone abroad wants a thing, someone with a plane ticket brings it, money changes hands. Once you try to model it, it becomes a small distributed-systems problem. Two parties who have never met, a purchase made with the carrier's own money, days of travel, and a single moment in an arrivals hall where everything has to settle.

This post is a design walkthrough of that problem as a state machine. It is conceptual on purpose: there is no contract code here and no addresses. The one product fact we rely on is how Qrrier describes its own flow: USDC escrow on Base, released at the handoff with a one-time code. Everything else is the reasoning a builder would go through to arrive at something like it.

The payout problem that shapes everything

Start from the carrier's side, because that is where the design pressure comes from. On Grabr, a well-known marketplace in this space, the help center says travelers should expect payment 3 to 15 business days after a delivery is confirmed (checked October 30, 2026). Qrrier pays out at the moment of handoff.

A long payout window is not a bug in those systems. It is the price of building on card rails, where money can be pulled back weeks later. If you want the carrier paid the instant the item changes hands, you need settlement that is final at that instant. That requirement drives most of the decisions below.

The states

Here are the eight states and what each one means:

And the transitions, drawn as plain text:

Posted -> Matched -> Funded -> In transit -> Handoff code -> Released
             |          |            |              |
             v          v            v              v
         (cancel)   Refunded <- Disputed <----------+

A few design rules that fall out of this

Money only exists from Funded onward. Posted and Matched are pure coordination. They can live entirely in the application layer, be edited freely and be cancelled without any on-chain action. Keeping them off-chain avoids paying network fees for listings that never turn into deliveries.

Funding must happen before the purchase. If the traveler buys first and the shopper funds later, the traveler is extending credit to a stranger. Putting Funded before In transit means the traveler can verify the order is backed before spending anything.

There are exactly two terminal states for money. Every funded order ends in Released or Refunded. No "partially settled" limbo, no balance stuck in a platform wallet. That invariant is easy to state and easy to audit.

Disputes must be raised before release. Once the code is entered, the payout is final. That means the window for complaints is the handoff itself: the shopper inspects the item first and withholds the code if something is wrong. The Disputed state is reachable from Funded, In transit and Handoff code, but not from Released.

The one-time code as a consent signal

The handoff code is the most interesting piece. It is not authentication in the usual sense. It is the shopper's consent, expressed in a form that works offline, in a noisy airport, without scanning anything.

Things worth thinking about when you design one:

• Single use. A code that works twice is a bug. Once it releases funds, it is spent.
• Held by the right person. Only the shopper (or the recipient they nominate) should see it. The traveler should never be able to retrieve it.
• Brute-force limits. A short numeric code is fine for humans, but entry attempts must be rate-limited and locked after a few failures.
• Coercion and social engineering. The product has to say clearly and often: never share the code before you have the item in your hands.

Why stablecoins rather than card holds

The obvious alternative is a card authorization hold: authorize the shopper's card when the order is matched and capture when the item arrives. It breaks down for this use case in three places.

1. Holds expire. For most merchant categories a card authorization lapses within about a week, and longer holds are limited to specific categories. International trips with shopping time often run longer than that.
2. Capture is not final. Even after capture, cardholders can usually dispute a charge for months, commonly up to 120 days. A platform that pays the traveler instantly would be carrying that risk itself, which is exactly why card-based marketplaces hold payouts.
3. Cross-border friction. The shopper and the traveler are in different countries by definition. Card payouts to individuals abroad mean FX spreads, bank cut-off times and different rails per country.

USDC on Base addresses each of those:

• The lock lasts as long as the order needs. Escrowed funds do not expire after a week.
• Settlement is final. Once released, there is no chargeback path. That is what allows an instant payout without the platform underwriting weeks of risk.
• One currency for both sides. A dollar-pegged token means the reward is the same number to the traveler in Texas and the shopper in Porto Alegre, and Base keeps transaction fees low enough that a modest reward is not eaten by gas.

It is fair to name the costs too. Shoppers need a way to acquire USDC, travelers need a way to cash it out, and both depend on the stablecoin issuer and the network. Stablecoin rules also differ by country. These are real tradeoffs, not footnotes.

The payout timing tradeoff

Instant release moves risk around rather than removing it.

• With a holding period (days after delivery), the shopper can complain after the fact, and the platform has time to claw back. The traveler pays for that safety with waiting time and uncertainty.
• With release at handoff, the traveler is made whole immediately, but the shopper's protection has to be front-loaded: inspection before the code, the right to refuse, and a dispute path that only applies before release.

For hand-carried goods, front-loading is a reasonable choice. The shopper is physically holding the item when they decide. Defects that only show up weeks later are a warranty matter with the manufacturer, not a delivery dispute.

A worked example (prices checked October 30, 2026)

A developer in Porto Alegre wants a Magic Keyboard with Touch ID and Numeric Keypad (USB-C), US English, white keys. A traveler flying home to Brazil from Texas accepts the order.

• US price: Apple's US online store lists it at US$179.00 before sales tax.
• Brazil price: Apple's Brazilian online store lists the same US English model at R$1,899.00.
• Rate: European Central Bank reference rate for October 30, 2026, R$5.4325 per US dollar.

US$225.54 is about R$1,225, compared with R$1,899 locally, a saving of roughly 35%. If the traveler pays a sales tax of around 8% in the store, the saving is still about 30%. At Released, the traveler receives US$214.80 (the item price plus the reward) in USDC. Brazil's duty-free allowance for air travelers (US$1,000 at the time of writing) covers everything in the traveler's bag combined, so check Receita Federal's current rules before flying.

What a builder should take away

• Keep coordination states off-chain and money states minimal: funded, released, refunded.
• Fund before purchase so nobody extends credit to a stranger.
• Make release final and put all buyer protection before it.
• Treat the handoff code as consent: single use, rate-limited, never visible to the carrier.
• Choose the settlement asset for finality and cross-border reach first, and be honest about the on-ramp and off-ramp costs.

This article describes design reasoning and one product's published flow. It is not financial advice, and prices and rates will have changed since they were checked.

Try the flow

• qrrier.com
• Qrrier on the App Store
• Qrrier on Google Play

Qrrier Team, business@qrrier.com

A developer in Curitiba wants a MacBook Air 13" (M5, 16 GB / 512 GB). In Brazil it costs R$15,999. A traveler flying Miami to São Paulo next week could buy it in the US for $1,299.

The developer worries: "If I pay first, will this person disappear?" The traveler worries: "If I buy first, will I ever see my $1,299 again?"

Peer-to-peer delivery only works if both questions get a confident "yes." This post breaks down how Qrrier answers them, layer by layer.

Layer 1: money moves first, but nobody holds it

The shopper funds the order before the traveler spends anything. The funds sit in a non-custodial escrow, a smart contract holding USDC on Base. The shopper can pay by card (converted to USDC via an on-ramp) or in USDC directly.

Two things follow from that:

• The traveler isn't extending credit. They can see the order is funded before they walk into a store.
• The platform isn't a bank. Qrrier never holds carrier funds, and there's no internal Qrrier wallet that money sits in or gets withdrawn from.

Layer 2: a 4-digit delivery code as the handshake

At hand-off, the recipient inspects the MacBook (sealed box, right model, right spec) and then shares a 4-digit code. That code is the only thing that tells the escrow "delivered."

It's a deliberately low-tech handshake. It works at an airport arrivals hall, a café or a front door, and no one has to scan a QR code in poor signal or upload photos.

Layer 3: an instant payout is a trust feature

This is the part that gets overlooked. Trust isn't only "will the stranger pay me?" It's also "when?"

On many platforms, the traveler finishes the delivery and then waits in a "processing" state. Grabr's own help center, for example, puts the payout window at 3 to 15 business days once the buyer signs off, plus bank time. For a $1,299 laptop, that can mean up to two or three weeks of the traveler's money in limbo.

On Qrrier, the code entry is the payout. The moment the recipient enters the code, the smart contract sends USDC to the traveler's connected wallet. No queue, no request form and no minimum balance. The traveler in our example walks out of the café with their $1,299 back plus a $259.80 reward.

Removing the waiting removes a whole category of anxiety, and support tickets.

Layer 4: identity and reputation

• Email verification is standard for every account.
• Government ID verification is optional, and those who complete it carry a stronger signal.
• Two-way ratings mean shoppers rate travelers and travelers rate shoppers.

Layer 5: the right to say no

Travelers can inspect anything they're asked to carry and refuse it at hand-off. Guns and ammunition, hazardous materials, anything illegal, alcohol, tobacco and prescription-only medicine are excluded, and both countries' customs rules always apply. Nobody should ever carry a sealed box they haven't seen inside.

Layer 6: when things go wrong

If the laptop turns out to be sold out or the wrong spec, or the meet-up falls through, an admin steps in and the shopper gets the escrow back. See trust & safety for the details.

So, is the MacBook worth it?

Here's the order, with Brazil's customs handled properly. Brazil gives air travelers a US$1,000 allowance and charges 50% on the excess.

That's the kind of number that makes a stranger worth trusting, if the system is built so you don't have to rely on trust alone.

Not just laptops

The same model protects the things that matter most and are hardest to ship:

• Jewelry: a gold set for a wedding moving from Dubai to Dhaka, or an engagement ring from London to Auckland. Hand-carried, never in a warehouse.
• Documents: original degree certificates from Lagos to Toronto, or a notarised contract from Mexico City to Madrid.
• Homemade food: sealed tamales from Guadalajara to Chicago or dried fish and spices from Dakar to Paris, packed to customs rules. Couriers often refuse these. Travelers can carry them.

Package deliveries work like shopping orders. The sender pays the agreed base plus 15%, the traveler gets 95% of the base, and the same code-triggered instant payout applies. Many routes deliver next day, because the traveler is the shipping method.

The short version

If you travel between continents a few times a year, whether that's Europe and Africa, the Americas and Asia, or Oceania and the Gulf, there's probably a MacBook-sized gap in your bag that someone would pay to fill.

Start at how it works, or see what travelers typically earn on the carriers page.

App Store · Google Play

Prices are approximate and change often. Always check current customs and airline rules for your route.