Escrow,
in one link.
Nexrow holds your client's USDC the moment the deal is agreed, and pays you the second they approve. No bank, no account, no 10% cut.
- Take rate
- ~1%
- Settlement
- ~400ms
- Fee per tx
- Sub-cent
- MVP
- 14 days
01Thesis
Overview
The thesis, and the one line it all compresses into.
Nexrow is a single shareable link that holds a client's USDC in escrow the moment a deal is agreed, and releases it to the freelancer on approval in seconds, for a fraction of a cent, with no bank, no account, and no 10% cut.
Thesis
Cross-border freelancers get paid late, in the wrong currency, through platforms that take 10-20% and hold funds for days. The person doing the work carries all the trust risk: they deliver first and hope the client pays.
Nexrow flips this. The wedge is the link. The company is what grows on top of it: invoicing, reputation, recurring clients, and a payments graph of who reliably pays whom.
Upwork is a marketplace that happens to do escrow. Nexrow is escrow that becomes a network. We start where the pain is sharpest and the users are already crypto-native: the Superteam-style global freelancer earning in USDC who has no good way to make a stranger pay them safely.
The key insight
Escrow is not a feature of a marketplace. It is the smallest unit of trust in cross-border work, and it is shareable. A marketplace has to acquire both sides. A link brings the second side with it.
Status, as of July 2026: this is built, not just proposed
The escrow program is deployed and running on Solana devnet (program DJ7iTN4V1Du3N6akVUvQdyn6QVb9B7jgWPEkeuh89kX2), and the app signs real create, fund, release, and cancel transactions against it. The 36-test suite includes five security guards that were mutation-verified: each guard was deleted, the program rebuilt, and the matching test confirmed to fail, then the guard was restored byte-identical. What is not yet true is stated plainly throughout: devnet only (not mainnet), unaudited, and an upgrade authority still held by a single developer key. The rest of this page documents what exists, and marks what is still ahead.
02Thesis
The Ten Questions
Direct answers, no hedging.
- 01
What is the startup idea?
A single-link USDC escrow for freelancers. Agree scope, client funds the link, work is delivered, client approves, funds release instantly. Timeout auto-release protects the freelancer if the client goes silent.
- 02
What problem does it solve?
The freelancer-side trust gap in cross-border work: deliver-first-hope-to-get-paid, plus slow settlement, FX loss, and platform fees of 10-20%. For clients, it solves “how do I not get scammed paying a stranger overseas.”
- 03
Who is the target user?
Cross-border independent workers who already touch crypto: Superteam bounty hunters, Solana/web3 freelancers (designers, devs, writers), and small agencies in Nigeria, India, SEA, LATAM. Beachhead: the Superteam Earn community itself.
- 04
Why should this exist on Solana specifically?
USDC on Solana settles in ~400ms for sub-cent fees. Escrow of a $150 job is economically pointless on Ethereum and impossible on rails that need a bank. Solana Pay, Blinks, and a mature USDC float make a link-native, mobile-first escrow actually viable. The network choice is load-bearing, not cosmetic.
- 05
What makes the idea possible now?
Deep USDC liquidity on Solana, Blinks/Actions making a payment shareable as a link on X, and a large already-onboarded population of crypto-paid freelancers who feel this pain weekly.
- 06
What would the first version look like?
It now exists and runs on Solana devnet. A freelancer creates an escrow (amount, description, payout wallet, timeout) and gets a shareable link, the client opens it and funds a program-owned vault, the freelancer delivers off-platform, the client clicks Release, and if the client never acts the funds auto-release after the timeout. Create, fund, release, and cancel all sign real on-chain transactions. It is devnet only and unaudited so far.
- 07
How would it make money?
0.5-1% fee on release (versus Upwork's ~10%). Later: flat fee per large escrow, premium features, and compliant float/yield on held USDC.
- 08
What competitors exist?
Upwork/Fiverr escrow, traditional escrow.com, crypto invoicing tools (Request), and generic multisig/Squads.
- 09
Why is this better/faster/cheaper?
Cheaper (~1% vs ~10%), faster (seconds vs days), simpler (a link, not an account or marketplace), portable (any client, any chat, no lock-in).
- 10
Why should Sumiro launch this?
It's the exact shape Sumiro already ships (Sharebox = paid action as a single link). The target user is Sumiro's own network (Superteam partner). Clean 14-day MVP with an obvious money moment and a real path from feature to company.
03Thesis
Problem & Users
Who is bleeding, and where.
Problem statement
Independent cross-border workers have no lightweight, trustless way to guarantee they'll be paid for work delivered to a stranger, and clients have no cheap way to prove they'll pay only for work received.
Existing solutions are marketplace-locked, expensive, fiat-slow, or too technical.
Personas
Ada, the freelancer
Lagos designer paid in USDC. Chases invoices, and lost money to a client who ghosted after delivery. She wants proof of funds before she starts, and an instant payout when the work is accepted.
Marcus, the client
Runs a small DAO/startup and hires globally. He wants to pay only for delivered work, without wiring money to strangers or trusting an unknown contractor with an advance.
The asymmetry
Today the freelancer carries 100% of the trust risk and the client carries none. Nexrow does not move the risk to the client, it removes it from both by putting the money in a program neither side controls.
04Thesis
Why Solana
The network choice is load-bearing, not cosmetic.
- Fees
- Sub-cent, so a 1% take on a $100 job is viable and small escrows make sense. On Ethereum, gas can exceed the fee itself.
- Speed
- ~400ms finality. Release feels like Venmo, not like a bank transfer.
- USDC depth
- USDC is the settlement asset these freelancers already hold. No conversion story to sell.
- Distribution
- Solana Pay gives QR funding, and Blinks/Actions let a client fund straight from a tweet.
- Population
- The users are already on Solana, via Superteam and the bounty ecosystem.
- Culture
- The consumer-app, low-friction ethos fits a one-link, tap-to-pay product.
Why it would not work elsewhere
Escrow on a $150 job is economically pointless on Ethereum (gas can exceed the fee) and impossible on rails that need a bank account on both ends. Solana is the only place where link-native, mobile-first, sub-cent escrow of small amounts is actually viable.
05Thesis
Why Now
Three things converged, and none of them were true two years ago.
- Deep USDC liquidity on Solana: the settlement asset is finally sitting in the users' wallets by default.
- Blinks/Actions: a payment can now be shareable as a link on X, so the funding step lives where the conversation already happens.
- A large, already-onboarded population of crypto-paid freelancers (Superteam, bounty platforms) who feel this pain weekly, not theoretically.
The window
The rails, the distribution surface, and the users arrived at the same time. The product is not waiting on a technology that does not exist yet, it is waiting on someone to put a link around it.
06Product
Product (PRD)
Goals, non-goals, requirements, and what done means.
Goals
- G1
- Create a fundable escrow link in under 60 seconds, with no signup.
- G2
- Guarantee payment on approval or timeout, without trusting the client.
- G3
- Keep take-rate under 1% at launch.
- G4
- Make the client flow feel like paying an invoice.
Non-goals (v1)
- Decentralized or staked arbitration (a basic single-arbiter dispute path did ship, see below)
- Fiat on/off ramp
- Milestone splitting
- Teams
- Native mobile apps
- Reputation scoring
User stories
- As a freelancer, I create an escrow and send the link.
- As a client, I fund the link.
- As a client, I release the funds when the work is delivered.
- As a freelancer, I get paid by auto-release if the client goes quiet.
- As a freelancer, I see the live status of every escrow I have created.
Functional requirements
- FR1
- Create escrow: amount, title, description, wallet, timeout.
- FR2
- Generate a shareable link, copyable and with a scannable QR of that link. (A native Solana Pay request and a Blink are roadmap, not shipped.)
- FR3
- Fund via connected wallet, signing a real on-chain transaction.
- FR4
- On-chain escrow account with the state machine Created → Funded → Released / Refunded / AutoReleased, plus, when a party opens a dispute, Funded → Disputed → ResolvedRelease / ResolvedRefund / ResolvedSplit.
- FR5
- Release, and cancel-before-funding.
- FR6
- Timeout auto-release.
- FR7
- Per-wallet dashboard.
- FR8
- Fee on release, routed to the treasury.
Non-functional requirements
- Sub-3s perceived flow
- Mobile-first
- No account required to fund
- Wallet sign-in via a nonce and signature (email/password auth also shipped)
- Audited before mainnet (the program is currently unaudited and devnet only)
- Graceful RPC failure
Acceptance criteria
One sentence, testable, and now passing on devnet
A freelancer with no prior account can create and share a funded escrow, and a client with a wallet can fund and release it, and the freelancer receives the funds minus the fee, on devnet, in under 5 minutes. This runs end to end against the deployed program today. Mainnet, an audit, and low caps are the remaining gate before real money.
Risks
- Dispute abuse
- The 80% case is handled by approve-or-timeout. A basic dispute path also shipped: either party can freeze a funded escrow, and an arbiter resolves it (release, refund, or split). The arbiter is a single hot key today, which is itself a risk, see the Appendix.
- Regulation
- Non-custodial by design: funds move wallet to program vault to wallet, and there is no pooled Nexrow balance. Get counsel before touching fiat.
- Contract risk
- Deployed to devnet with a 36-test suite and five mutation-verified guards, but unaudited. External audit and low caps before mainnet.
07Product
MVP Scope
What shipped, and what deliberately did not.
Shipped (live on devnet)
- Create escrow, signing initialize_escrow on-chain
- Shareable link with a copyable URL and a QR of that link
- Fund via connected wallet, signing a real on-chain transaction
- On-chain state machine, including the dispute and resolution states
- Release by the client
- Cancel before funding
- Timeout auto-release, cranked by a scheduled keeper
- Per-wallet dashboard, read back from the chain
- Fee on release, routed to the treasury from the Config PDA
- Supabase auth, profiles, settings, notifications, and dispute records, with RLS
- Wallet sign-in via a nonce and signature
- Dispute open plus a single-arbiter resolution console (release, refund, split)
- Non-custodial wallet view (no pooled Nexrow balance, no deposit or withdraw)
Out of scope (still)
- Decentralized or staked arbitration
- Fiat ramps
- Milestones
- Teams
- Native mobile app
- Reputation
- Solana Pay funding and Blinks distribution
- Email and Telegram notifications (in-app notifications did ship)
Definition of done
Done means live, not demoable
The full loop is live on devnet: a new freelancer creates and shares a funded escrow, a client funds and releases it, and the freelancer receives the funds minus the fee, in one session with no manual intervention. The remaining gate to calling it done for real money is mainnet, an external audit, low caps, and moving the upgrade and arbiter authorities off single keys.
What actually got built
Step 1
Positioning, naming, scope freeze
Locked the one-liner, the name, and the boundary of v1.
Step 2
Branding, landing, escrow UI
Brand system and landing page, the escrow creation and funding UI, and the wallet adapter.
Step 3
Anchor program, tested, deployed to devnet
Wrote the on-chain program (escrow plus a Config PDA for treasury and arbiter, disputes, and arbiter resolution), covered it with a 36-test LiteSVM suite, mutation-verified five of the security guards, and deployed to devnet.
Step 4
Wired the frontend, Supabase, keeper, arbiter console
Wired create, fund, release, and cancel to the deployed program, stood up Supabase (auth, profiles, settings, notifications, dispute records, RLS) with wallet sign-in, added the timeout keeper, and built the arbiter console. Audit and mainnet are the remaining post-sprint work.
08Product
Product Architecture
What was built. The program is the source of truth for funds, and no pooled balance ever touches our servers.
Overview
A Next.js web client, a Solana program (Anchor, deployed to devnet) that is the source of truth for funds, USDC as the value layer, and Supabase as an off-chain record and index layer for reads, accounts, and notifications.
One thing was added that was not in the original plan: a Config PDA, a platform singleton that holds the treasury and arbiter authorities outside any escrow. It exists so that the escrow creator (the freelancer) can never name themselves the arbiter and self-resolve. The admin can rotate treasury or arbiter through update_config without redeploying the program.
No pooled Nexrow balance ever exists: funds move wallet to program vault to wallet directly. The one honest caveat is the program's upgrade authority, covered under Trust and security below.
Components
Frontend
Next.js and React, with a wallet adapter for Phantom, Backpack, and Solflare. The share surface is a link (/e/[id]) with a copy button and a QR of that link. A native Solana Pay request and a Blink are on the roadmap, not shipped.
On-chain program
Anchor and Rust, deployed to devnet at DJ7iTN4V1Du3N6akVUvQdyn6QVb9B7jgWPEkeuh89kX2. A PDA per escrow owns a per-escrow vault token account. Instructions: initialize_config, update_config, initialize_escrow, fund_escrow, release, cancel, timeout_release, open_dispute, resolve_release, resolve_refund, resolve_split. The fee is routed to the treasury on release.
Config PDA
A platform singleton (seed "config"), created once, holding admin, treasury, and arbiter. Kept off the escrow so neither party can appoint the arbiter. The admin can rotate keys via update_config with no redeploy. This was not in the original design.
Supabase
The off-chain record and index layer: auth, profiles, settings, notifications, and dispute records (evidence and messages), all under row-level security. Non-authoritative for funds. If it goes down, the money is unaffected and reads self-heal from the chain.
Keeper (auto-release crank)
A scheduled server-side job that signs timeout_release for expired escrows with a dedicated keeper key. On the current Vercel Hobby cron it runs about once a day, so auto-release is not instant at the moment the window closes. Anyone can also trigger timeout_release directly against the program.
Arbiter console
A dispute-resolution surface gated by a logged-in session, a server-only admin allowlist, and a per-resolution operator-wallet step-up signature. The on-chain resolve_* instructions still require the arbiter key recorded in the Config PDA.
State machine
+---------+ fund_escrow +--------+ release +----------+
| Created | ---------------> | Funded | ---------------> | Released |
+---------+ (client funds) +--------+ (client approves)+----------+
| | |
| cancel | | timeout_release
| (creator, before fund) | | (anyone, after timeout_at)
v | v
+----------+ | +--------------+
| Refunded | | | AutoReleased |
+----------+ | +--------------+
| open_dispute
| (either party)
v
+----------+
| Disputed |
+----------+
| resolve_release / resolve_refund /
| resolve_split (arbiter only)
v
+-----------------+ +----------------+ +---------------+
| ResolvedRelease | | ResolvedRefund | | ResolvedSplit |
+-----------------+ +----------------+ +---------------+
initialize_config runs once, setting the treasury and arbiter in a
Config PDA the parties do not control. initialize_escrow is signed by
the freelancer and creates the account in Created. The program vault
holds the USDC, never Nexrow.Data model
| Field | Type | Notes |
|---|---|---|
| escrow PDA | Pubkey | Program-derived from ["escrow", creator, seed]. One per escrow. |
| creator | Pubkey | Freelancer who created the link. Authority for cancel only, never a payout. |
| freelancer_wallet | Pubkey | Where the payout goes. May differ from creator. |
| payer | Pubkey | Client wallet. Pubkey::default() until funded, then set to whoever funds. |
| mint | Pubkey | The SPL mint held in escrow (USDC). |
| vault | Pubkey | This escrow's token account, a PDA whose authority is the escrow. |
| amount | u64 | Escrowed amount, in the mint's base units. |
| fee_bps | u16 | Fee in basis points, snapshotted at creation (default 100, 1%). Deducted on release. |
| timeout_at | i64 | Unix timestamp. After this, anyone can trigger timeout_release. |
| seed | u64 | Caller nonce, so one creator can hold many live escrows. |
| status | enum | Created, Funded, Released, Refunded, AutoReleased, Disputed, ResolvedRelease, ResolvedRefund, ResolvedSplit. |
The Config account
Separate from the escrow, a single Config PDA (seed "config") holds admin, treasury, and arbiter. It is created once by initialize_config and updated only by the admin via update_config. Keeping treasury and arbiter here, out of the escrow struct, is what stops a freelancer from naming themselves the arbiter. This account did not exist in the original plan.
Trust & security
- Funds sit in a per-escrow program vault, not in any Nexrow-controlled wallet. There is no pooled balance.
- Between the two counterparties, the money is neutral: the creator can only cancel or receive a payout, never trigger one to themselves, and the client is the only one who can release.
- Timeout is triggerable by anyone after expiry, so the freelancer never depends on Nexrow being online. In practice the keeper does it, roughly once a day on the current host.
- A dispute freezes the escrow. Only the arbiter recorded in the Config PDA can resolve it, and neither party can appoint that arbiter.
- Unaudited, and devnet only. An external audit and low caps come before mainnet.
The strongest evidence: mutation-verified guards
We did not just write tests, we proved they bite
The program ships with a 36-test LiteSVM suite, one test per non-negotiable invariant. For five of the security guards we went further and mutation-verified them: each guard was deleted from the source, the program rebuilt, and the corresponding test confirmed to fail, then the guard was restored byte-identical. That is direct evidence the guard is load-bearing and the test would catch its removal, which is a stronger claim than a passing test on its own. It is still not a substitute for an external audit.
The honest limit on "non-custodial"
Against the currently deployed rules, if Nexrow disappeared every funded escrow could still be released or timed out by the counterparties directly against the program. But the program's upgrade authority is a single developer keypair (A9JyaJtpFKNvf1pD1phs7GPq1mEi2VpCniyFD9kfCiSW). Whoever holds it can deploy different rules and reach every escrow, so any flat "Nexrow cannot touch your money" claim is not true as written today. The mitigation is to move the upgrade authority to a multisig before mainnet. Until then, this stays on devnet.
09Product
UX Flow
Three flows. Every screen answers one question: where is my money right now.
Flow 1: Freelancer creates
01
Land and create
Land on the page, click Create escrow. No signup, no account.
02
Enter the deal
Amount, title, scope, timeout. Confirm the receiving wallet.
03
Sign
Sign initialize_escrow. The escrow account exists on-chain, unfunded.
04
Share
Get the link and a QR of it. Send it to the client in whatever chat they already use.
Flow 2: Client funds
01
Open the link
The client sees an invoice-like card: who, how much, for what, and the line that matters, “your money is held, not spent.”
02
Connect
Connect a wallet. (Scanning the QR opens the same link on a phone; native Solana Pay funding is roadmap.)
03
Approve
Approve fund_escrow, a real on-chain transaction. The card flips to Funded, and the freelancer can start with proof of funds.
Flow 3: Release
01
Deliver
The freelancer delivers off-platform, in whatever tool the work already lives in.
02
Client approves
The client clicks Release and approves. Funds move to the freelancer, minus the fee, instantly.
03
Or the client goes quiet
If the client never returns, then after the timeout the funds release to the freelancer. The keeper does this automatically, though on the current host it runs about once a day, so it is not instant at the moment the window closes. Anyone can also trigger timeout_release directly.
Flow 4: If it goes wrong, a dispute
01
Freeze
Either party opens a dispute on a funded escrow. That flips it to Disputed, which freezes both release and the timeout crank.
02
Review
Evidence and messages are recorded off-chain in Supabase. An arbiter reviews them in the arbiter console.
03
Resolve
The arbiter resolves on-chain: release to the freelancer, refund to the client, or a split. Today the arbiter is a single key, and moving it to a Squads multisig is the roadmap fix.
Dashboard
A per-wallet dashboard lists every escrow the connected wallet has created or funded, with live status. It is a read surface over on-chain state, so it is never the authority on where the money is, it only reports it.
Design principles
It should feel like paying an invoice, not like using a chain. Every screen answers “where is my money right now.” No jargon on the client side. Mobile-first, with the primary action thumb-reachable.
10Plan
Product Roadmap
From a link, to an invoicing layer, to a payments network.
Already live on devnet, the base the roadmap builds on
Deployed Anchor program, on-chain create, fund, release, cancel, and timeout, dispute plus single-arbiter resolution, the auto-release keeper, Supabase auth, profiles, settings, notifications and dispute records, wallet sign-in, and the non-custodial wallet view. Backed by a 36-test suite with five mutation-verified guards. The roadmap below is what comes after that.
- External security audit
- Move the program upgrade authority to a multisig
- Move the arbiter to a Squads multisig
- Faster auto-release crank (the Hobby cron runs ~once a day)
- Mainnet at low caps
- Solana Pay funding and Blink distribution on X
- Invoicing layer
- Milestone escrows
- Freelancer profiles and reputation v1
- Email and Telegram notifications
- Decentralized or staked arbitration
- Team and agency accounts
- Recurring retainers
- Fiat off-ramp partners
- Payments graph and credit signals
- Embeddable API
Read the roadmap as a compounding line
Each phase makes the next one cheaper. The link brings clients in, invoicing keeps them, reputation makes the choice of freelancer non-random, and the payments graph is the thing no marketplace can copy without owning the escrow.
11Plan
OKRs
Q1 proves the loop. Q2 proves it is a business.
Q1
Ship an escrow strangers actually use
- 100 mainnet escrows
- 60% of funded escrows reach Release or Auto-release
- Median create-to-fund under 10 min
Validate the Superteam beachhead
- 30 unique Superteam freelancers complete a real paid job
- 3 unsolicited public testimonials
Q2
Show willingness to pay the fee
- $50k cumulative GMV
- <5% churn to competitors after first use
- Fee revenue covers infra plus audit amortization
Build the network wedge
- 20% of new escrows from a previously-seen client wallet
- Reputation v1 with 200 profiles
The one metric that decides everything
20% of new escrows coming from a previously-seen client wallet is the moment Nexrow stops being a tool and starts being a network. Every other KR is a precondition for that one.
12Plan
Revenue Model
We earn when the freelancer gets paid. Not before.
Primary
A 0.5-1% fee on successful release, deducted from the released amount. The deployed default is 1% (100 basis points), snapshotted into each escrow at creation and routed to the treasury on release. It scales with volume, and the incentive is aligned: we only earn when the freelancer actually gets paid.
Secondary (roadmap)
- Flat fee on large escrows
- For example, $1 flat above $2,000, so big jobs are not overtaxed.
- Premium subscription
- $9-19/mo for agencies and power freelancers: milestones, invoicing, team seats.
- Float / yield
- Compliant yield on held USDC.
- Embedded / API
- B2B2C escrow as a primitive other products can call. Later.
Unit economics
Cost per escrow is near-zero on Solana. At a 1% fee, contribution margin is effectively the fee minus negligible infra.
The constraint is GMV, not cost. That is exactly why the repeat-client loop matters more than any pricing optimization.
The comparison that sells itself
On a $2,000 job, Upwork takes roughly $200. Nexrow takes roughly $20. The freelancer keeps the difference, and the client pays a stranger without trusting them.
13Plan
Go-to-Market
Start in the room where the users already are.
Beachhead
The Superteam Earn community. They are the users, they are already here, and the sponsor is a Superteam partner. We launch by dogfooding real paid work through Nexrow and screen-recording it.
Wedge motion
Single-link virality. Every escrow link is a marketing surface. The client experiences Nexrow as a payer, and becomes a potential repeat client or a freelancer themselves. The links travel through Telegram, X DMs, and Discord, which is exactly where the deals are already being agreed.
Channels
- X threads, and (roadmap) Blinks so a client can fund straight from the timeline.
- Superteam Discord/Telegram and the regional chapters: Nigeria, India, SEA, Vietnam, Turkey.
- Founder-led public build logs, and “I got paid in 3 seconds” clips.
- Payment-horror-story content, which the audience writes for us.
Positioning
The positioning statement
For cross-border freelancers tired of getting paid late and losing 10% to platforms, Nexrow is a single link that holds your client's money before you start and pays you the instant they approve. No bank, no account, no marketplace.
Launch sequence
01
Devnet demo plus thread
Prove the loop publicly before a dollar is at risk.
02
Mainnet low-cap beta
30 hand-picked freelancers, real jobs, real money, tight caps.
03
Public launch
Testimonials plus a Blink, so the launch post is itself a funding surface.
04
Regional rollout
Chapter by chapter, through the Superteam network.
14Plan
Marketing Strategy
Sell the fear, then show the 15-second proof.
Core narrative
“You did the work. Now hope you get paid.” → “Never work on trust again.”
The emotional hook is being ghosted after delivery, which every freelancer in this audience has lived. The proof is a 15-second instant-release clip. Fear, then relief, in under a minute.
Content pillars
- Payment pain stories
- Build in public
- Educational: how escrow protects you
- Proof and testimonials
Community-led growth
- Referral: a reduced fee for both sides when a user brings a paying client.
- Superteam chapter ambassadors.
- A public leaderboard of GMV protected.
Solana-unique distribution
The channel no fiat competitor has
On the roadmap, Blinks let the funding action live inside a tweet. Escrow.com cannot put a fundable escrow in a timeline, and Upwork does not want to. Today the share surface is a link and a QR, and the Blink is the next step.
Metrics
- Activation: create-to-fund rate
- Virality: clients who become creators
- Retention: repeat clients
- Word-of-mouth
15Analysis & Pitch
Competitive Matrix
Where the incumbents win, where they cannot follow, and where we sit.
| Criterion | Nexrow | Upwork / Fiverr escrow | Escrow.com | Request / crypto invoicing | Squads / multisig |
|---|---|---|---|---|---|
| Take rate | ~1% | 10-20% | 0.89-3.25%+ | ~0-1% | Gas only |
| Settlement | Seconds | Days | Days | Minutes | Minutes |
| Needs a bank | No | Yes | Yes | No | No |
| Needs an account | No (wallet) | Yes | Yes | No | Yes (setup) |
| Marketplace lock-in | No | Yes | No | No | No |
| Handles disputes | Basic (single arbiter) | Yes | Yes | No | Manual |
| Built for solo freelancer | Yes | Yes | No | Partly | No |
| Works over any chat/link | Yes | No | No | Partly | Partly |
| Mobile-first | Yes | Partly | No | Partly | No |
Scroll the table sideways to see every competitor.
Reading the matrix
Our whitespace
Incumbents win on dispute handling and trust brand, but lose on cost, speed, lock-in, and simplicity. Crypto tools win on cost, but are not usable escrow for a solo freelancer. Nexrow's whitespace is escrow-grade guarantee with link-level simplicity at near-zero cost, with a basic single-arbiter dispute path shipped and decentralized arbitration roadmapped.
16Analysis & Pitch
Pitch Deck
Fourteen slides.
Title
Nexrow: get paid the moment they say yes.
Problem
You deliver first, and hope. Ada's story.
Solution
A link that holds the client's money before you start, and pays you in seconds on approval.
Demo
15 seconds: create, fund, release. Real USDC on devnet, against the deployed program.
Why now
USDC depth, plus Blinks, plus a population of already-onboarded freelancers.
Why Solana
Sub-cent fees, ~400ms finality, Solana Pay, Blinks.
Market
The global freelance economy. Beachhead: Superteam-style crypto freelancers in NG, IN, SEA, LATAM.
Product
Built and live on devnet: on-chain escrow, disputes, keeper, Supabase, wallet sign-in. 36 tests, five security guards mutation-verified. Roadmap: link → invoicing → reputation → network.
Business model
~1% on release, versus Upwork's ~10%. Premium and float later.
Competition
The matrix, and our whitespace.
Go-to-market
Superteam beachhead, single-link virality, chapter rollout, Blinks.
Plan
Q1 prove the loop. Q2 prove the business. (The OKRs.)
Why Sumiro
Same shape as Sharebox, their network is the user, and it is a clean 14-day MVP.
Ask
It is already built and running on devnet. Back the audit, the move to multisig authorities, and the mainnet launch with the Superteam community.
17Analysis & Pitch
Appendix
Glossary, ranked risks, and the naming rationale.
Glossary (client-facing)
- Escrow
- Money held safely until the work is approved.
- Release
- Pay the freelancer.
- Timeout
- Auto-pay the freelancer if the client goes quiet. Handled by the keeper, and triggerable by anyone.
- Dispute
- Either party freezes the escrow so no one can move the money until an arbiter decides.
- Arbiter
- The neutral party who resolves a dispute (release, refund, or split). A single key today, a multisig later.
Top risks, ranked against what is actually exposed now
- 1. Upgrade-authority key compromise
- The program's upgrade authority is a single developer keypair. Whoever holds it can deploy different rules and reach every escrow. Mitigation: move it to a multisig before mainnet, and stay on devnet until then. This is the real one now.
- 2. Unaudited contract
- A 36-test suite and five mutation-verified guards raise confidence, but they are not an audit. Mitigation: external audit and low caps before mainnet.
- 3. Single-arbiter compromise or capture
- One hot key resolves every dispute. Mitigation: move the arbiter to a Squads multisig.
- 4. Money-transmission regulation
- Mitigation: non-custodial design (no pooled balance, no deposit or withdraw), plus counsel before touching fiat.
- 5. Disputes and trust at scale
- A basic single-arbiter path shipped, but it does not scale and is centralized. Mitigation: the decentralized-arbitration roadmap.
- 6. Cold-start beyond Superteam
- Mitigation: single-link virality, plus the chapter network.
One honest line for judges
What is real, and what we are not claiming
What is real: the program is deployed to devnet, the app signs real create, fund, release, and cancel transactions, disputes and single-arbiter resolution work, and five of the security guards are mutation-verified, not just tested. What we are not claiming: it is not on mainnet, it is not audited, the upgrade authority and the arbiter are still single keys, and the dispute path is basic. We solve the 80% case (an honest client, with ghosting risk) with approve-or-timeout, and we name the audit, the multisig authorities, and decentralized arbitration as the work that turns a working prototype into something that can hold real money.
Naming rationale
Nexrow is next-generation escrow, compressed. It means held safely, and kept-your-word.
It is short, it works as a verb (“I'll Nexrow you the link”), it has a clean domain surface, and it carries no crypto jargon, which matters because half the people who receive the link have never used a wallet.