What actually belongs in one, and how you get one
The checklist tells you what you need. This is what the thing itself actually looks like: the key elements, in plain language and in the real code behind this demo.
The four-part shape of any smart contract
Before the code, the mental model. Every contract in this demo, and most enterprise ones, breaks down into these four parts.
Facts it remembers
Who's involved, how much money, and what stage things are at right now.
Actions it allows
The specific things that can happen: confirm delivery, verify, approve, pay.
Rules that gate each action
Who's allowed to do what, and in what order. This is the access control.
Announcements it makes
A permanent, timestamped record of everything that happened: the audit trail.
What that looks like in code
You don't need to read code to use this system, but “the code” shouldn't be a black box either. This is the actual contract behind the demo on this site, in Solidity, the programming language most Ethereum contracts are written in, simplified slightly for readability.
License & version
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;Which version of the Solidity language the code follows, and confirmation it's open-source (MIT license). Think of it like specifying which version of a template a document was built with.
State variables: the facts it remembers
address public immutable buyer;
address public immutable supplier;
uint256 public immutable amount;
Status public status;
bool public deliveryConfirmed;
bool public qualityApproved;The facts the contract remembers permanently: who the buyer and supplier are, how much money is involved, and what stage things are at. Once written, nobody can quietly edit these.
Events: the announcements it makes
event DeliveryConfirmed(uint256 timestamp);
event ConditionsVerified(uint256 timestamp);
event SettlementApproved(uint256 timestamp);
event PaymentExecuted(address to, uint256 amount, uint256 timestamp);Every time something happens, the contract announces it. This is exactly what generates the instant audit trail both parties see, with no separate reconciliation needed afterward.
Modifiers: the guard rails
modifier onlySupplier() {
require(msg.sender == supplier, "not the supplier");
_;
}
modifier atStatus(Status expected) {
require(status == expected, "wrong stage");
_;
}Reusable rules checked before an action is allowed to run: “only the supplier can call this” or “this can only happen at this stage.” This is what access control actually looks like in code.
Constructor: the one-time setup
constructor(address _supplier, string memory _invoiceReference) payable {
buyer = msg.sender;
supplier = _supplier;
amount = msg.value;
status = Status.Created;
}Runs exactly once, when the contract is created: filling in the two parties' names, the amount, and the starting stage. After this, it never runs again.
Functions: the actions
function confirmDelivery() external onlySupplier atStatus(Status.Created) {
deliveryConfirmed = true;
emit DeliveryConfirmed(block.timestamp);
}
function executePayment() external atStatus(Status.Approved) {
status = Status.Executed;
supplier.call{value: amount}("");
emit PaymentExecuted(supplier, amount, block.timestamp);
}The same four actions from the walkthrough: confirm delivery, verify, approve, execute payment. Each one is gated by the modifiers above, and each one ends by announcing the event that updates the audit trail.
How do you actually get one?
Three real paths, in order of how much you build versus buy.
Write custom code
A developer, yours or a vendor's, writes it from scratch in Solidity. Full control over the business logic, but it carries the most security review burden, since nothing has been tested by anyone else first.
Start from an audited template
Most enterprise patterns, like escrow, multi-signature approval, or token payments, have well-tested, publicly audited starting points (OpenZeppelin is the most common) that get customized rather than written from a blank file. Faster, and generally safer, than starting from zero.
Use an enterprise platform
Some vendors, like trade finance networks or supply-chain platforms, provide pre-built, configurable contract templates as part of a broader product. You configure business terms through a form rather than touching code directly. Fastest to deploy, but still worth vetting the vendor's own audit history.
For something like the invoice contract in this demo, most enterprises start from an audited escrow template and add the delivery-confirmation logic on top, then get that customization audited before it goes anywhere near real funds. See the security guides for what that audit actually checks.