Smart Contracts: Follow the Deposit, Data and Authority

Imagine a delivery deposit of 100 units. Before calling its smart contract “self-enforcing,” identify whose confirmation can release the money, which record the program changes and who can alter the release rules. Those dependencies explain what the payment button actually does—and where the advertised promise still relies on outside information or authority.

This guide follows a fictional delivery deposit through a contract. The example is a reading exercise, not a design to deploy or a recommendation to deposit money. Its purpose is to show where a seemingly simple promise depends on code, information and people.

Start with the address, function and state

Ethereum’s developer introduction describes a contract as code and stored data at an address. A transaction can call one of its functions. The function operates on the stored state, which might include a balance or a record of who may withdraw it.

For our fictional deposit, imagine three entries: buyer, seller and amount held. A function called “confirm delivery” is meaningful only when you also know whose confirmation it accepts and what that confirmation changes. The reassuring name of the button does not supply those details.

Draw a small ledger on paper. Write “buyer deposited 100 units,” then leave a space for the next permitted change. Would a seller’s signature release the funds? Must the buyer sign? Could a third account resolve a dispute? Each answer describes a different system, despite an identical deposit screen.

This is why reading the advertised purpose and understanding the actual permission are separate tasks. “Escrow” describes an intended job. The rules determine whether the program performs that job in the circumstances you care about.

Execution is not independent judgment

NIST’s Blockchain Technology Overview, particularly sections 6 and 7.3, explains that participating computers must reach the same result from contract execution. It also describes the difficulty of connecting recorded information to events outside the system.

In our example, the ledger can record that someone submitted “delivered.” It cannot establish that the box contained the right item merely because that word appears in a transaction. Someone or something has to provide the relevant information. An oracle supplies outside data; it does not make every input true.

Try changing one sentence in the fictional arrangement. Instead of “release payment after delivery,” write “release payment after the approved courier reports delivery.” The second version exposes a dependency the first version concealed. You can now ask what happens if the courier reports the wrong address or its service stops responding.

Those are questions for the particular implementation. There is no universal refund rule for a missing input. Record the unanswered question rather than assuming the contract will choose a fair outcome.

A deadline needs a path to action

The Ethereum introduction explains interaction through transactions. In a design that works this way, the passage of time can make a function permissible without anyone actually calling it.

Suppose the deposit rules permit a refund after Friday. Saturday’s calendar date and a completed refund are different facts. For this fictional contract, ask who submits the refund transaction and what information that caller needs. If a service promises to do it, that service becomes another dependency to inspect.

Separate the reading exercise into three lines:

• Condition: the deadline has passed and the release condition is unmet.
• Authority: this account is permitted to request the refund.
• Action: a transaction invokes the function that changes the recorded balances.

This separation helps identify vague automation claims. A timer in an app interface may display eligibility. It does not, by itself, demonstrate that funds have moved.

Correct execution can still produce a harmful result

Ethereum’s security guide explains reentrancy: an external call can let another contract call back before the original operation finishes. Its example shows why updating a balance after sending funds can allow repeated withdrawals. The guide also warns that an audit will not catch every bug.

The lesson is about the ordering of operations. An intended rule such as “withdraw your balance once” is incomplete if the implementation leaves a moment when the old balance is still usable. The network can execute the program’s instructions while those instructions fail to express the designer’s intention.

For a nontechnical reader, an audit is evidence to investigate, rather than a label that ends investigation. Ask which code version and components were reviewed, and whether the report identifies unresolved findings. Do not infer that a review of one component covers the entire arrangement.

Find out what can change

Ethereum’s upgrading documentation distinguishes deployed code from the logic an application executes. An upgrade pattern can direct interactions to a different implementation while retaining state. That makes “the code is immutable” an insufficient description of the application’s future behavior.

Return to the deposit sketch. Add a fourth line: “Who can alter the release logic?” If there is an upgrade authority, ask how it operates. If there is none, ask how a serious defect would be handled. These questions reveal a tradeoff; they do not establish that either arrangement is always preferable.

Keep the answers in a compact table:

A contract is easier to assess when each promise has its own evidence. If a presentation answers only the first row, the remaining rows are still open. Publicly visible code can help a competent reviewer examine those questions, but visibility alone is not a verdict on safety.