The problem TrustDrop solves

The Problem

For the past few months, I got into making digital assets in Blender. What started as a hobby quickly turned into freelance opportunities — but the experience was brutal:

1. Buyers steal work. You send the file, they ghost. Your hours of work, used for free.
2. Sellers scam buyers. Pay first? The seller disappears or delivers garbage.
3. Previews lie. What you saw isn't what you got. No way to verify.

TrustDrop Fix-

1. Every uploaded file is AES-256-CBC encrypted before it's stored. The raw file doesn't exist in a downloadable form anywhere — not on the server, not in the preview, not in the browser. The decrypted file is only generated after the Locus Checkout payment is verified on-chain. No payment means no file. No screenshots of the real thing either — buyers only see Agent generated cinematic previews, not the actual asset.
2. Seller cannot sell garbage-> TrustDrop agent makes the preview of the file uploaded for the buyer to confirm first.(No room of cheating)=> Agent does verification for you.

As a new creator on Discord or Twitter, trust is nonexistent. Buyers won't risk money on an unknown seller. Sellers won't risk their work on an unknown buyer. Both sides lose — the buyer misses a talented creator, the seller never gets their shot.

TrustDrop Fix-

The Improvement Room solves this too. A buyer who commits funds is putting skin in the game — the seller knows the buyer is serious. And if the buyer ghosts after seller delivers? The commitment fee is released to the seller as compensation. Both sides have something to lose, so both sides act in good faith.

Fake portfolios, stolen assets, and fabricated reputation have become a nightmare across online creator communities.

Existing platforms don't fix this:

• Gumroad takes up to 23% in fees

• Etsy requires KYC, card details, and bank accounts — excluding young creators globally
  somehow they create subscription plans.

• Neither offers cryptographic proof that the delivered file matches the preview

TrustDrop Fix-

Minimal platform fees on purchases — 100% of the payment goes to the seller via Locus Pay. No KYC, no bank account, no credit card required. Sellers just need a Locus wallet address to start selling. Buyers can even tip creators via email — the recipient gets a claim link from Locus to collect USDC without needing a crypto wallet at all. And on-chain USDC payments can't be reversed or clawed back like PayPal chargebacks.

No verification. No protection. No access for emerging talent.

TrustDrop provides all three: dual on-chain verification (webhook + session status polling), automatic escrow protection with deadline-based resolution, and a zero-barrier entry for any creator anywhere in the world i.e a PAYOUT WORLD. This solves one of the most hinged payout session problem over the internet using Locuscheckout architecture. Millions of designers(Roblox , Minecraft , blender builds) , coders , assets builder does transaction on daily basis can now easily Sell and Pay with TrustDrop securely.

Challenges we ran into

1. Production vs Beta API — Checkout Failing on Day One

The very first time we tried to run a Locus Checkout session, it failed immediately. The checkout iframe wouldn't load, and API calls returned errors. We were pointing at 'api.paywithlocus.com' (the production endpoint) — but our 'claw_dev_' API key only works against the beta environment.

Fix: Changed the API base URL from 'https://api.paywithlocus.com/api' to 'https://beta-api.paywithlocus.com/api' and the checkout URL to 'https://beta.paywithlocus.com'. Environment and API key have to match — dev keys only work against beta, production keys only work against prod. A small misconfiguration, but it blocked the entire payment flow until we caught it.

2. Locus Pay API Field Names — The Silent Payout Failure

The first major blocker hit when seller payouts silently failed with 400 errors. After a buyer purchased a listing and payment landed in the platform wallet, the server tried to forward funds to the seller — but every call to '/pay/send' failed.

Root cause: The Locus API uses 'to_address' (not 'to'), expects 'amount' as a number (not a string), uses 'memo' (not 'reason'), and returns 'transaction_id' (not 'txHash'). Every single field name was wrong.

Fix: Corrected all field names and response parsing in 'lib/locus.ts'. Confirmed with a live test showing funds forwarded to the seller wallet. This taught us to never assume API field names — always test with real calls first.

3. BWL Upload Size Limit — The 5KB Wall

Sellers couldn't upload files larger than ~5KB. The upload would silently fail with no error message. After extensive debugging, we discovered that BWL's reverse proxy blocks large request bodies.

Fix: Moved file uploads entirely to Supabase Storage with client-side direct uploads via signed URLs. The server generates a signed upload URL ('/api/upload/signed-url'), the client uploads directly to Supabase (bypassing the BWL proxy), and the server downloads from Supabase server-to-server for encryption. This pattern works for files of any size.

4. The Checkout Popup That Kept Dying

The commitment fee payment in the Improvement Room used Locus Checkout in 'popup' mode, which opened a new browser tab. But browser popup blockers immediately killed the tab — the buyer had no chance to pay. On some browsers it would flash open and close within a second.

Fix: Switched to 'mode="embedded"' which renders the checkout inline as an iframe. But this introduced a new problem — the embedded iframe locked scroll on the entire chat area. Fixed by wrapping the checkout in a 'max-h-[350px] overflow-y-auto' container, keeping the chat scrollable while the checkout renders inline.

5. The Invisible 409 — Commitment Payments That Vanished

This was the hardest bug to find. After switching to embedded checkout, buyers could pay the commitment fee successfully — the checkout showed a success screen — but nothing happened. No commitment message appeared in chat, no timer started, no deadline was set. The money left the buyer's wallet and went to the platform, but the commitment was never created in the database.

Root cause: After checkout success, the frontend called '/api/room/[id]/commit/confirm' which called 'verifyPaymentOnChain()'. But the on-chain verification returned false because Locus hadn't propagated the transaction yet (takes a few seconds). The endpoint returned a 409 error — but the embedded checkout iframe was covering the error UI, so the failure was completely invisible. The commitment row was never inserted, which meant no chat message, no timer, no refund path.

Fix: Added retry logic — up to 5 attempts with 3-second intervals. The UI shows "Verifying payment... attempt 2/6" so the buyer knows something is happening. The checkout iframe auto-dismisses after success, revealing the retry progress. This alone fixed the entire commitment flow.