New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
An early Blockchains Manager article describes blockchain contracts as a way to prevent cheating. That claim compresses several separate questions into a single reassuring phrase. Did software execute the published rule? Did the rule reflect the parties' intended agreement? Were the facts supplied to it accurate? Could anyone correct an error or settle a dispute? A smart contract can address parts of that sequence without answering the whole sequence. This guide uses a hypothetical delivery-payment arrangement to show where the boundaries sit. It does not describe a service offered by this site or claim that any particular historical contract was secure.
A rule can be precise and still be the wrong rule
Suppose a buyer and seller want payment to follow delivery. A simple software condition might release funds when a delivery-status field becomes true. That is precise enough to implement, but it leaves the meaning of delivery unresolved. Does it require arrival at a warehouse, acceptance by an employee or confirmation that the contents meet the order? If the parties have different answers, executing the condition consistently does not remove their disagreement. It simply chooses one interpretation before the disagreement becomes visible to everyone involved in the transaction.
The specification should therefore describe observable states rather than rely on a familiar business word. It can distinguish dispatched, arrived, inspected, accepted and disputed. For each transition, identify the actor allowed to propose it and the evidence required to support it. This exercise often reveals that the important work happens before any contract code is written. The code needs an exact account of the process, including exceptional cases, because computers cannot recover the parties' unstated expectations from a label such as complete.
External inputs cross a trust boundary
Ethereum's oracle documentation explains why contracts need a separate mechanism for facts originating outside the chain. An oracle supplies information that on-chain execution can use. That information might concern a delivery, a weather observation or a reference price. Recording it on a blockchain makes it available to the contract; the recording step alone does not prove that its real-world interpretation is correct. In the delivery example, the design still depends on whoever or whatever reports the relevant status and on the method used to resolve conflicting reports.
A useful review follows one input from observation to contract consumption. Who observed it? How was it authenticated? Could it be delayed, duplicated or associated with the wrong order? What happens if the source becomes unavailable? These questions should be asked even when the input comes from a well-known organisation. Reputation and technical authentication answer different questions. A correctly authenticated message from the expected source can still contain an operational error, and a fresh message can still describe an event that occurred much earlier than the system assumes.
Agreement about data is not agreement about reality
Several reporting parties can reduce dependence on one observer, but a count of reports is not a complete quality measure. Three services may all obtain their information from the same underlying database. They can then agree perfectly while sharing a single point of failure. In the hypothetical shipment process, three logistics dashboards might repeat the same scan. Their agreement establishes consistent distribution of that scan, not three independent inspections of the goods. The relevant question is how the evidence was produced, not how many interfaces display the result.
This distinction suggests a practical test: remove one underlying source and see which supposedly independent reports disappear together. Then examine incentives. If every reporter benefits when a transaction settles quickly, the design needs an account of who is motivated to report a defect. None of this requires assuming that every participant is dishonest. It requires recognising correlated errors and conflicting responsibilities. A system can be carefully coded and still make a poor business decision because it received several versions of the same incomplete observation.
Code review and process review solve different problems
Solidity's security guidance treats smart-contract development as an activity that demands explicit attention to pitfalls and defensive design. A software review can investigate access controls, unexpected execution paths and interactions with other contracts. It cannot, on its own, establish that a delivery policy is commercially sensible or that an external inspection is genuine. These reviews should inform one another without being treated as interchangeable certificates. A successful code test says something about the tested implementation and assumptions; it does not turn every surrounding assertion into a verified fact.
For the delivery example, organise tests around specific failures. A reporter submits the same status twice. An acceptance arrives after a dispute. The buyer and seller use different order identifiers. An administrator attempts a change outside the intended approval process. The expected outcome should be written before the test runs. This turns security from a badge into a set of observable properties. It also makes omissions easier to discuss because the team can point to an untested transition rather than argue about whether the whole system deserves to be called trustworthy.
Design the remedy alongside the automation
Automation changes how quickly an action happens, so it can change how quickly an error becomes expensive. If payment is released immediately after a report, the process needs a clear answer for a later discovery that the report was wrong. Possible designs include a waiting period, a dispute state or a separate reconciliation process. Each changes the experience for participants. The appropriate choice depends on the workflow; there is no universal setting that makes every automated payment both instant and readily reversible under all conditions.
Describe remedies in the same level of detail as the normal path. Who can pause a disputed order? What evidence is retained? Can a participant inspect the reason for an intervention? What happens if the person responsible for resolving the dispute is unavailable? A pause mechanism itself introduces authority and operational dependencies, so it needs limits and visibility. Omitting remedies does not eliminate those dependencies. It often pushes them into informal support conversations where decisions become harder to reproduce and participants cannot see which rule was actually applied.
Explain the full guarantee in ordinary language
The strongest description of an automated agreement is specific about its boundaries. It might say that the published software releases payment after an authorised inspection report, subject to a defined challenge process. That statement is less dramatic than a promise to eliminate cheating, but it gives a reader something meaningful to evaluate. It identifies the software action, the outside authority and the available remedy. It also leaves room to discuss the consequences of a compromised key, a faulty report or an administrator acting outside the documented process.
The historical article remains useful as evidence of how blockchain's potential was presented. A new explanation should make the hidden dependencies visible. Treat code execution as one component of a larger agreement, not as a substitute for an account of external facts. Map the reporting path, test the exceptional states and describe the remedy before declaring the process complete. The result is a more practical understanding of smart contracts: software that can enforce defined transitions, embedded in a world whose observations, institutions and disagreements still need to be handled explicitly.
Technical references
From the recovered archive
- Blockchain is changing the world! · captured 6 October 2024