DEV Community

Nenzy Brown
Nenzy Brown

Posted on

WordBond mechanics: a seller's promise, backed by a bond that actually pays out

WordBond got a short mention in my flagship post here last week, so I'll skip the pitch and go straight to the machinery, because the machinery is the only part worth arguing about.

The problem it aims at: a seller online says "delivery in three days" and there's nothing behind the sentence. No deposit, no penalty, just vibes. WordBond makes the seller post a bond in a vault contract. If the promise breaks, the buyer gets paid out of that bond automatically. No ticket, no chargeback form, no chasing anyone.

Where it runs today

Base Sepolia. Testnet. I want that in the second paragraph, not the footer: the pilot at https://wordbond-pilot.netlify.app uses a mock USDC token and test money only. The vault contract is live on Sepolia and anyone can read its state — that's the point of running the pilot in public instead of on a slide.

The flow, step by step

A seller deposits a bond into the WordBondVault. When they make a promise — this order, this coverage amount, this deadline — the contract checks the bond actually covers the promise plus the fee, and reverts if it doesn't. Half-covered promises can't be registered. That rule alone kills the most obvious way to game it.

The registration fee is 2% of coverage, read straight from the contract. On 100 of coverage, exactly 2.00. The buyer gets a delivery code. When the goods arrive, the buyer confirms with that code and the promise closes as kept. If the deadline passes with no confirmation, the promise breaks and the payout fires on its own.

What the live testnet run showed

I ran it end to end with real transactions, not a demo script. One promise kept through the buyer code. One left to expire on purpose — and the buyer was paid exactly 90 out of the 100 coverage, with 10 going to the fee address. Not roughly. Exactly. The numbers on the public board still show the three states side by side: $100 kept, $100 broken, $100 live.

Building the board taught me the pilot's best lesson. My first frontend read the contract through an interface I'd assumed instead of the one I'd deployed, and it would have shown a broken promise as kept. I fixed it with a raw read layer against the real contract functions and said so publicly at the time. A trust product that misreports its own states deserves whatever it gets.

What's deliberately not there

No owner withdrawal, no pause button, no upgrade path in the vault. There's a 7-day cooling lag on pulling a bond back out, so a seller can't drain the bond the night before a deadline. Mainnet stays locked until there's real gas money, an audit, and legal advice — in that conversation, not before it.

If you sell anything online and a stranger has ever asked "but how do I know you'll deliver" — what would a bond have to look like before you'd post one?

Top comments (0)