P2P maker cash-out spike (post-M5)

[Hazyshades]

Outcome

Prove or reject a maker-side P2P cash-out path for Sendly: the user who exits USDC deposits into escrow, waits for a buyer fiat payment with attested proof, and receives fiat without installing a browser extension.

Context

M5 covers embedded USDC funding only (#45). Instant bank cash-out is a separate candidate (#69). This spike covers a third route: peer-to-peer escrow cash-out where Sendly's user is the maker.

Target flow to investigate

USDC on Arc
 -> transfer or bridge to settlement-chain USDC
 -> escrow deposit at the live oracle or market rate (zero spread at fill)
 -> buyer signals intent and pays the maker through a supported fiat rail
 -> attested payment proof (for example TEE-TLS over the fiat provider)
 -> protocol releases USDC to the buyer

Design defaults for this spike (replace only with dated evidence):

• Settlement asset for the escrow leg is canonical USDC on a supported EVM cash-out chain. Base USDC is the first candidate to evaluate.
• Starting with settlement-chain USDC is the minimal path. An Arc-origin balance needs a live transfer or bridge route before deposit.
• Funds sit in protocol escrow contracts during the order, not in a Sendly-hosted off-ramp balance.
• The SDK or integration layer does not hold user keys.
• The maker can withdraw unmatched funds. If a buyer intent expires unpaid, withdraw must prune that intent before returning available USDC.

Maker product rules

• The cashing-out Sendly user is the maker only. Sendly does not need a full taker, vault, custom-spread, or dispute surface for this spike.
• The Sendly user must not install a browser extension for the supported maker path.
• Some fiat rails can accept a payee identifier (for example a UPI VPA or platform handle) without a seller bank-connect or extension step. Record which rails meet that bar.
• Buyer payment proof is a separate actor and path. Do not assume Sendly's existing Reclaim zkFetch social-identity proof is fiat-payment proof.
• Record who verifies the fiat payment, which fields bind the payment to the escrow order, and who may release USDC after proof.

Rate and UX honesty

• Fill uses the live oracle or market rate at execution with zero protocol spread in this design.
• estimate style amounts are approximate, may go stale, and are not a locked quote. Show them as approximate.
• Do not put "P2P always gets a better rate" in the product UI. Compare the final fiat amount after Arc to settlement-chain transfer cost and wait time against Instant bank cash-out.

Lifecycle states to support

Rebuild order state from protocol data rather than inventing a local state machine. Minimum states to account for:

• awaiting buyer;
• matched (buyer intent locked);
• delivering / partially filled when applicable;
• delivered (fiat proven, USDC released);
• returned (maker withdrew remainder).

Persist a durable order or deposit id as the resume key for watch, top-up, and withdraw.

Wise exclusion

Do not assume Wise as a P2P payout rail for this spike. Wise's published crypto policy prohibits receiving money for P2P sales of crypto assets (Wise Help). Revisit only with an explicit written allowance for the chosen scenario.

Acceptance criteria

• Spike notes cover Arc to settlement-chain USDC transfer, escrow deposit, maker role, extension-free maker path, buyer-proof actor, and withdraw or unmatched-funds behavior.
• Extension-free maker path is demonstrated for at least one fiat rail, limited to a documented subset, or marked blocked.
• Social zkFetch is not treated as fiat-payment proof.
• Rate comparison uses final amount after transfer cost and wait time, not a marketing claim of always-better P2P rates.
• Estimates are documented as approximate and not locked quotes.
• Wise is excluded unless a dated written allowance exists for the scenario.
• Go or no-go for a later P2P cash-out pilot is recorded with sources and date checked.
• M6 row approval (M6: Mainnet Launch Gate #62) remains required before any production P2P cash-out enablement.

Dependencies

• M5 embedded funding (M5: Embedded USDC Funding Pilot release gate #45) does not depend on this spike.
• Instant cash-out feasibility (Instant cash-out feasibility (post-M5) #69) is a separate candidate path and may compete on corridor and UX later.

Non-goals

• No production P2P cash-out integration in this spike.
• No M5 on-ramp scope change.
• No claim that P2P escrow replaces Circle Onramp or Instant bank payout.
• No buyer-side intent, custom spread, vault, or dispute product surface in this spike.

[Hazyshades]

Follow-up after M5 embedded funding. Parent gate: #45.