What actually happens behind Created, Verified, Approved, and Executed
The demo shows four stages moving in sequence. This page explains the mechanism behind each one, and where the contract fits inside the larger system it depends on.
How validation actually works
What “Verified” and “Approved” really check
Each stage below is a specific, checkable event, not a black box. Here is the mechanism behind each one.
Created
The supplier (or a connected logistics system) submits delivery confirmation on-chain.
Mechanism
That submission is cryptographically signed with the supplier's private key. The network checks the signature against the supplier's registered address before accepting the record, so no outside party can file a fake delivery event.
Why it can be trusted
The record is timestamped and appended to the ledger. Once confirmed, it can't be edited or deleted, only added to.
Verified
The contract compares the delivery record against the terms agreed when the contract was created.
Mechanism
This is deterministic rule evaluation: quantity, unit price, purchase-order number, delivery window, and quality thresholds are all checked in code. The same check runs independently on every validating node, and they must all agree on the result before "Verified" is accepted.
Why it can be trusted
Because every node re-runs the identical check, no single party, including the buyer or the supplier, can quietly alter the outcome. A short-shipped quantity or a mismatched PO halts the contract instead of letting it proceed.
Approved
All verification conditions returned true.
Mechanism
Approval is a logic gate, not a person: if goods delivered AND invoice matches purchase order AND quality passed AND terms are within window, then approved. There's no inbox, no queue, and no one positioned to sit on it.
Why it can be trusted
The approval rule itself was agreed and locked in by both parties before the contract went live, so neither side can change the rules mid-transaction to their advantage.
Executed
The approved state is reached.
Mechanism
Releasing payment and updating the status happen inside a single atomic transaction: both occur together, or neither does. There's no partial state where funds move but the record doesn't update, or the reverse.
Why it can be trusted
The completed transaction, and every step that led to it, is permanently visible to both organizations: a tamper-evident audit trail instead of two internal systems reconciled after the fact.
One distinction worth keeping straight: the contract's own logic (Verified, Approved) runs entirely on-chain and is deterministic. The event that starts the process, delivery confirmation, comes from the real world, which means it depends on an oracle or trusted data feed. That handoff is exactly where the security section below applies.
The bigger picture
Smart contracts are one layer, not the system
Everything demoed above lives in a single layer of a larger stack. Automating settlement means all of these layers have to work together.
Business systems
Supplier and buyer ERP, procurement, and finance platforms: where the process starts and ends.
Integration layer
APIs and middleware that translate purchase orders, invoices, and delivery notes into a format the contract can act on.
Smart contract layer
The automated rules engine walked through above: Created, Verified, Approved, Executed.
Oracle / data layer
Real-world signals (delivery scans, IoT sensors, carrier tracking APIs) that feed the contract.
Settlement layer
The banking rails or on-chain transfer that actually moves funds once the contract executes.
Security & compliance
Not a layer of its own. It runs underneath and across every layer above, from the ERP integration to the settlement rail. Covered in detail next.