The delivery truck is at the right address. Should the supplier get paid? Ask the driver and you might hear yes. Ask the person counting 18 cartons against an order for 20 and you’ll get a different answer. Both people saw the same delivery. Only one of them checked the condition on the purchase order.
That’s a useful way to think about a smart contract. It’s a program on a blockchain that can carry out an agreed action, such as releasing funds, when someone submits a transaction that meets its rules. It can check a signed receipt. It can’t look in the back of the truck.
Before you automate a payment, try the witness test. What event earns the money, who or what can reliably observe it, and do both parties accept that evidence? Here’s how those questions play out in five business processes, starting with the one you can try on paper.
1. Pay a supplier when the right goods arrive
Suppose a shop owes $600 for 20 cartons. The buyer and supplier agree that one payment is due when the receiving clerk signs for all 20 against the correct order. The driver’s arrival starts the unloading. The signed count releases the money. If the order arrives two cartons short, the clerk records 18, the payment stays on hold, and the purchasing lead contacts the supplier. When the missing two arrive, someone checks the cumulative count against the original order. Replaying the first receipt must never pay the invoice twice.
Where does a blockchain get that receipt? An oracle is the service that carries outside information to the contract. Choosing the warehouse system as your source means trusting how its staff count, correct and sign for goods. A timestamp tells you when somebody entered “20.” It doesn’t tell you whether they counted carefully. Ethereum’s guide to oracles explains how outside data reaches a contract.
Walmart Canada gives a real example of what shared freight records can do. In 2020, the retailer reported that invoice disputes with its carriers fell from over 70% at peak times to under 2% after it adopted DL Freight. The part worth borrowing is how the invoice reached the payment system: the parties agreed on the underlying charges, and the invoice went into the retailer’s existing software. The published figures describe Walmart’s experience. Walmart Canada’s account
Try the worksheet with someone from the other side of the transaction. The editable Word file has a blank rule sheet and a completed version of the 20-carton example. Fill in your own rule independently, then compare what each of you meant by “delivered.” That conversation can save you the cost of building the wrong thing.
Smart Contract Pilot Worksheet
2. Release a milestone payment from escrow
A design studio agrees to deliver three approved files for the first instalment on a job. Writing “pay on completion” leaves the hardest decision to whoever opens the folder. A more useful trigger is a signed acceptance from the client’s named project lead identifying the milestone and file version. Once that approval reaches the contract, it can release the agreed amount from funds set aside for the job. The client still decides whether the artwork meets the brief.
What happens if the lead is on holiday, asks for another revision or rejects the files outright? Decide who can stand in, how long the studio should wait and where either side can raise a dispute. If both businesses are happy with their existing payment administrator and the real delay is finding the approver, try fixing that handoff first. A calendar reminder may do more for Friday’s invoice than a new escrow system.
3. Pay an insurance benefit when a weather index hits a threshold
Imagine a policy that pays a fixed benefit when a named weather station records less than 20 millimetres of rain during an agreed period. A reading of 19 meets that condition. Exactly 20 does not. A missing reading isn’t zero rainfall, either. The parties need an agreed fallback for missing data before anyone relies on the cover.
There’s a harder case. A grower might lose a crop while the station, several miles away, records plenty of rain. This mismatch between the index and the grower’s actual loss is called basis risk. A smart contract can apply the written threshold consistently while the grower still receives nothing. Explain that possibility in plain language alongside the payout rule, and give the grower a contact for a suspect reading. The World Bank discusses this trade-off in its review of index insurance for smallholder farmers.
4. Split royalties that reach a shared account
Two illustrators sell a digital print. They agree to split net receipts 70/30. If $100 reaches the agreed payment address after fees, the split allocates $70 to one illustrator and $30 to the other. Now try the uncomfortable question: what happens if a customer buys the print through a different storefront?
The split can only allocate money it receives. Sales through the second shop still need a statement and a way to settle up. Before writing the rule, agree which sales count, how you handle refunds and who updates a recipient’s payment address. Run one discounted sale and one refund through the books. If the partners can’t agree on the $100 line of the statement, they aren’t ready to automate it.
5. Exchange collateral and cash together
A business delivering an asset faces an awkward interval if the other party’s payment arrives later. Delivery versus payment links the two transfers so that one side doesn’t deliver its asset while the other keeps the cash. J.P. Morgan describes an institutional example in its Kinexys digital financing service, where participants exchange cash for tokenized collateral and can program settlement and maturity times.
There’s a useful question here even for a team that will never trade securities. Can your system control both sides of the exchange? If it controls a digital record but someone must still hand over a physical asset or initiate a bank transfer elsewhere, map that last handoff separately. A record marked “settled” won’t make a missing transfer arrive.
Give one rule a dry run before commissioning a build
Take a morning’s worth of old orders and run your proposed rule beside the actual decisions, without moving money. Include one incomplete record, one duplicate and one correction. Write down every disagreement, who resolved it and what evidence they had. A rule that always needs the same manager’s judgement may belong in the approval software you already use. A shared contract is worth exploring when independent parties want the same rule to govern assets and agree on who can supply the evidence.
If you seek a quote for smart contract development, send the completed worksheet along with a troublesome receipt. Ask the team to show what happens when the feed goes quiet, who can pause payments, who can change the rules and how the other party would find out. Ask for separate costs for the data feed, transactions, security review and ongoing support. That gives you something more useful to compare than two estimates for “automation.”
Keep the commercial agreement handy as well. It should say what happens when the software’s result conflicts with the deal the parties understood. For context, the Law Commission’s work on smart legal contracts explains how existing law in England and Wales can accommodate them and identifies questions around deeds and jurisdiction. Have the people responsible for your agreement review your actual terms before a live pilot.
On that first delivery, the most valuable line in the worksheet might be the one that says “hold payment and call purchasing.” Give someone the authority to do that, and give them the receipt they’ll need when they pick up the phone.
About This Article
