Most smart contract conversations focus on tokens and trading. Far fewer explore what happens when code governs a physical asset. To test how this works in practice, I built a code-run O&M agreement where funds are committed in advance and released only when evidence of the completed work enters the record.
The technology to do this already exists. Whether it works for a real operating asset is a different question, and building one left me with another worth asking about your own O&M agreement: how much of it actually runs on the contract, and how much on the relationship?
What a smart contract actually does
When people hear the term "smart contract," they often imagine an automated decision-maker replacing human judgment. In reality, that's neither practical nor desirable for most O&M activities.
In this example, the smart contract doesn't decide whether an inverter should be replaced, whether a technician's assessment is correct, or whether a maintenance strategy makes sense. Those decisions remain in human hands.
Instead, it runs the agreement itself. It can hold funds, make sure each step happens in the agreed order, and keep a shared record of what was submitted, done, and approved. It runs on a blockchain, but there's nothing to speculate on. In practice, the owner deposits funds in advance, in digital dollars (a stablecoin), enough to cover the upcoming work, and both parties use a digital wallet to approve their steps. The README walks through the setup in plain language. The expertise still comes from people. The contract simply provides a more structured and transparent way to coordinate their work.
The real cost: reconstructing what happened
For an asset manager, moving the money is rarely the hard part. The hard part is chasing reports and supporting documentation, and later reconstructing everything that led to the payment.
A single maintenance visit leaves a trail: the request, the site visit, photos, the report, the approval, the payment. Each party keeps its own part of it, and no one holds the whole story. And that story has to hold together across the life of an asset, even as owners, operators, lenders, and service providers change.
Here, the key steps are recorded as they happen: what was submitted and when, who approved it, and when the payment was released, in one record both sides can see and neither can rewrite. The automation helps, but it isn't the main point. The evidence releases the payment, and the payment makes sure the evidence exists.
Why not escrow and ordinary software? Honestly, much of this could run that way: a shared platform with an audit log and a traditional escrow account would cover a lot of it. What a blockchain adds is narrower. Nobody has to trust a platform operator, the record outlives any single vendor, and anyone can check it later without asking permission. Whether that's worth the extra friction depends on how much those three things matter to you.
Rebalancing incentives: who does the code protect?
In a sense, both parties. The provider knows the funds are committed before the work begins. The owner knows payment is released only once the agreed evidence is on record. Both sides know the rules before the first wrench is turned. It isn't perfectly balanced, though. Committed funds and payment on silence favor the provider. In exchange, the owner takes on a clear responsibility: review each submission within the agreed window, or accept it by default.
It also changes the incentives. In construction, I've seen how much this matters: contracts tend to get what they pay for. Pay only for good news, and good news is what you'll get. So when my first instinct here was to pay only when the asset passed inspection, I changed it. The provider is paid for the service, and the finding goes on the record, good or bad. A problem found early becomes part of the work, not a threat to the invoice. That doesn't mean paying for paperwork. If a submission doesn't hold up, the owner can reject it, as long as the reason goes on the record too, and the provider gets a chance to put it right.
Most disputes I've seen didn't start with bad faith. They started with two reasonable people remembering the same agreement differently. A shared record won't settle who was right about the work, but it narrows the argument to the work itself, not to what was agreed, submitted, approved or paid.
A record built for disagreements
Most contracts are written as if everything will go wrong, while people sign them expecting things to go right. So if a contract exists partly to help the parties through future disagreements, shouldn't it also keep the evidence needed to resolve them?
This pilot is one way to do that. Every inspection, repair, rejection, and miss is recorded as it happens, in a record both parties contribute to and neither can rewrite on their own. In a live version, a report that resurfaces five years later can be checked against what was recorded on the day. In my last post, I wrote about a solar farm where knowledge that already existed had to be rebuilt from scratch after the asset changed hands. This pilot records inspections and repairs, not strategic decisions, but the principle is the same: capture the record when it's made, so it doesn't depend on who's still around.
And a record kept for disagreements turns out to be useful long after them. It's the beginning of a shared history of the asset, one a buyer or lender could check for themselves.
What surprised me: code doesn't do vague
What surprised me most was how much it takes to turn ordinary clauses into code that only understands yes or no. Getting close to how the work actually happens takes far more conditions than you'd expect, and the exercise kept asking me the same question: what if?
Most agreements leave room for interpretation, often on purpose. That isn't a flaw: flexibility helps people handle what nobody could anticipate when they signed. But code doesn't do vague. Questions a traditional contract could leave open suddenly need concrete answers, and you start to see how much has always been covered by experienced people using their judgment.
Creating an O&M agreement framework that runs as code is achievable. But some calls can't be written as code. So what exactly is being automated? A smart contract can confirm that evidence was submitted and hasn't changed since, and release the payment once the agreed conditions are met. People still decide what the evidence means, and what counts as good enough. In my experience, that's where agreement is hardest to find.
Say a provider repairs a damaged cable and submits the evidence. Whether the repair meets the standard, whether the root cause was found, whether the problem is actually solved: those are still calls for people.
Even oracles (data feeds that bring outside information, like sensor readings, into a smart contract) can't remove that judgment entirely. They can confirm that output is back; they can't tell you why it failed, or whether the fix will last. A careless inspection, recorded perfectly, is still careless.
Code has another edge: it doesn't bend. Once both sides accept the terms, they can't be renegotiated halfway through; changing anything means a new agreement. And it does exactly what was agreed: once a payment is released, it stays released, even if a problem surfaces the next day. If the legal agreement behind it were set aside, the code wouldn't know. That predictability is the point, and also the cost.
That's a trade-off worth making. Let the code handle the routine, so people can spend their time on the calls that need them.
So, back to the question I started with: code can handle more of an O&M agreement than most people realize, but the relationship still carries the rest, and that's where human time and attention matter most.
The pilot & GitHub repository
I built this to learn, and I'm sharing it for the same reason. It's an exploratory project on a test network with test dollars, covering one asset and two parties. Not a product, not a security, not audited.
The code is on GitHub, free to read, reuse or criticize, with a plain-language guide for anyone who doesn't read code. If you run assets or O&M contracts, I'd especially like to hear which rules you'd write differently.
Next time: what that history could mean for the asset itself.
