Stablecoin receivables platform
The product the KYC agent lives inside. Suppliers submit invoices, funders finance them in testnet USDC, and the platform takes a fee on the spread. Seven roles, thirty-odd screens, and a rule that every status change must be provable from the chain rather than asserted by a client.
The problem
A supplier ships in March and gets paid in May
Trade runs on credit terms the seller did not choose. Goods ship, an invoice is raised, and sixty days later the money arrives — while wages, materials and the next order all fall due immediately. Receivables financing closes that gap: a funder advances most of the invoice now and collects the full amount later, keeping the spread.
The friction is not the idea, it is the settlement. Cross-border payment legs are slow, opaque while in flight, and expensive enough to eat a thin spread. Stablecoin settlement is interesting here for one unglamorous reason: the transfer is final and publicly verifiable within a minute, which is exactly what a platform sitting between two counterparties needs.
The money flow
Six states, each provable
- 1. Supplier submits an invoice — who owes it, how much, when it is due.
- 2. The platform reviews it, sets an advance rate and fee, and approves.
- 3. A funder sends the advance in USDC — the invoice becomes Financed.
- 4. The platform forwards advance minus fee to the supplier — Disbursed.
- 5. The debtor pays the full amount through a no-login payment link — Repaid.
- 6. The platform forwards the full amount to the funder — Completed.

The decision I care most about
The database is never told what happened
The tempting build is: the browser completes a transfer, then posts “done, here is the transaction hash”, and the server advances the invoice. It works, it demos well, and it means a fabricated hash — or an honest client with a stale view — can move an invoice into a state no money supports.
Instead, every money route independently reads the transaction back from a public RPC and re-derives it before the database is touched: the recipient, the token contract, and the amount. If any of the three disagrees with what the invoice expects, the status does not move. The client's claim is a hint about where to look, never evidence.
It is the same shape as the agent's approval gate, arrived at separately: the component that wants the outcome is not the component allowed to record it.
Compliance
Seven roles, and a gate nobody can self-serve past
Self-serve signup creates exactly one kind of account: a supplier. Every internal role — admin, origination, compliance, compliance approver, funder — is created by an existing admin and arrives by invite. Access is per-screen rather than per-role, so a compliance analyst can be given the review queue without the payments ledger.

How the agent shipped inside it
Flagged off in production the whole time
The agent was built on a branch that never merged, behind a flag that defaults to off, and was demonstrated from a preview deployment. Production carried the code and refused to serve it for the entire build.

That is a small piece of engineering and a large piece of product argument. It is what let the agent be shown to compliance stakeholders as a real, clickable thing while the answer to “could this touch a live case?” stayed a flat no — and it is why the pilot plan can promise that one click switches it off.

Honest limits
What this is not
- No real money.Base Sepolia testnet and Circle's testnet USDC throughout. Nothing here has custody of anything.
- No escrow contract. The platform is a trusted intermediary that manually approves and forwards. A real product would put that logic on-chain; that is the obvious phase two and it is not built.
- One chain, one stablecoin. No multi-chain routing, no FX, no treasury management.
- Not security reviewed. It is a working demonstration of a money flow, not something to point real funds at.