中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC095
An AI agent saying “done” is not the same as an authorised action being submitted, executed and verified. An agent saying “stopped” is also not proof that an operation already sent to another system can no longer take effect. To understand the result, follow the action across the model, signing gateway, network and application state.
This lesson uses a harmless, fictional catalogue update. We compare interruption before and after submission, an application-level revocation in two possible orders and a later corrective update. The exercise contains no real keys, funded accounts, trades, deployments or external actions. Its purpose is to reconstruct authority and effects from evidence.
The central distinction is operational: stopping the process that proposed an action and stopping the action’s remaining execution path are different tasks. Sources were checked on 12 October 2026.
Choose your reading route
In this guide
- 1. Define the small action and its boundaries
- 2. Separate human authority from technical capability
- 3. Follow the baseline trace
- 4. Stop before the gateway acts
- 5. Revoke the application’s permission before execution
- 6. Reverse the order and observe the limit
- 7. Correct a completed effect without rewriting history
- 8. Read a receipt for what it actually says
- 9. Reconstruct attribution without inventing hidden intent
- 10. Exercise: identify the resulting state
- 11. Write an outcome report with the right scope
- Frequently asked questions
- Sources and further reading
Sections 1–3 define the actors, exact authorisation and baseline trace. Sections 4–7 test interruption and revocation timing. Sections 8–10 distinguish receipts, evidence and narration, followed by an exercise. The final report shows how to acknowledge a completed effect without implying that the AI controlled every stage.
Back to contents · Next section
1. Define the small action and its boundaries
Catalogue record R7 begins at revision 4 with label L0. Human controller H approves exactly one proposed change: set R7’s label to L1, provided the application still sees revision 4 when it executes the operation. A successful operation changes the label to L1 and advances the record to revision 5.
The approval does not cover R8, a different label, a later revision, permission changes or a second attempt with altered contents. This is a fictional exact-action approval for teaching; it is not an instruction to perform any real update.
AI agent A can read the supplied catalogue and propose a structured operation. It cannot access a signing key, change the independent gateway’s checks or directly write the catalogue. Gateway G is the sole signing and submission path in the model. There are no alternate credentials, delegated workers or hidden submission routes in the supplied facts.
That last assumption matters. A result about stopping one gateway would be weaker if another already held a usable signed operation. We make the action paths explicit rather than assuming a reassuring chat message covers every possible copy.
Back to contents · Next section
2. Separate human authority from technical capability
G receives H’s authenticated exact-action approval and compares it with A’s proposed fields. It signs and submits only the matching operation. This is a supplied independent enforcement boundary, not the AI’s promise to inspect itself.
The application also checks a separate onchain permission flag for G’s role at execution time. It requires that role to remain active and R7’s revision to equal 4. If either application condition fails, this toy operation produces no label or revision change. Fees and transaction-account mechanics are outside the model.
H’s approval and the application’s role are not interchangeable. H defines the intended permitted action. The application role determines whether a submitted operation can pass the specified execution gate. An overly broad application role would not expand H’s actual approval, even if it gave the gateway more technical power.
NIST’s AI Risk Management Framework 1.0 calls for defined and documented human-oversight processes and attention to component-level risks. Our actor map is a concrete teaching model for that kind of responsibility separation, not a claim that a framework document certifies this design. NIST AI RMF 1.0
Back to contents · Next section
3. Follow the baseline trace
At time 0, H’s exact approval is recorded. At time 1, A proposes the matching R7/revision-4/label-L1 operation. At time 2, G verifies the approval, signs the operation and submits it. At time 3, the receiving node acknowledges it and supplies transaction identifier T9. The operation has not yet executed in the baseline at that point.
At time 4, H stops A. The supplied stop succeeds: A produces no further proposals and cannot start another gateway request. It does not change the already submitted operation, and no separate application-role revocation is sent in this baseline.
At time 5, T9 executes. The role remains active and R7 is still revision 4, so the application sets label L1 and revision 5. At time 6, an independent observer confirms the supplied finality condition and reads the resulting R7 state at the identified accepted block.
The final state is label L1, revision 5, with A stopped. Those facts are compatible. Stopping A at time 4 did not retract the operation already handed to an independently running system.
The result also does not show that A disobeyed the stop. In this trace A performed no action after time 4. The later effect followed from the earlier authorised submission and the unchanged application gate.
Back to contents · Next section
4. Stop before the gateway acts
Variation B resets to the initial catalogue state. H stops A at time 1 before any request reaches G. The model supplies that G has not signed or submitted anything, and no other route exists. R7 remains label L0, revision 4.
This is a meaningful bounded prevention result. It depends on the evidence that no usable operation left the controlled path. Merely seeing an empty chat window would not establish that fact in a real system.
Variation C also resets. G has created a signed operation but has not submitted it. An authorised stop disables G’s submission step, and the exercise explicitly supplies that the signed bytes were not exported or copied elsewhere. No operation reaches the network, so no catalogue effect occurs.
Do not generalise C to “all signed transactions can be cancelled by stopping the agent.” Its success depends on the sole-path and no-export assumptions. Once a usable signed payload has reached another party or service, stopping one local process may no longer contain all possible submission paths.
These two variations show why a control report should identify the last completed handoff. “Stopped before proposal,” “stopped before signing” and “stopped after submission” describe different remaining risks.
Back to contents · Next section
5. Revoke the application’s permission before execution
Variation D resets again. T9 has been submitted, but a separately authorised administrator operation revokes G’s application role. The accepted execution order is explicitly given: role revocation first, then T9.
When T9 executes, its role check fails. Under the supplied toy rule, label and revision remain L0 and 4. The submitted transaction’s existence is not erased, but the intended catalogue mutation does not occur.
The useful fact is the effective application state at T9’s execution, not merely the time someone requested revocation. A revocation proposal sitting in another queue would not establish the same result. The exercise supplies its accepted position ahead of T9 so the outcome is unambiguous.
This is also a different action from stopping A or disabling G’s local interface. It uses a control enforced by the receiving application. A real design must identify whether such a control exists, who can invoke it and what operations it actually constrains.
We are not describing a universal blockchain cancellation mechanism. We are evaluating a particular application gate that was part of this toy’s rules from the start.
Back to contents · Next section
6. Reverse the order and observe the limit
Variation E changes only the accepted order: T9 executes before the authorised role revocation. At its execution, the role is active and revision is 4. R7 becomes L1, revision 5. The later revocation prevents later operations that require that role, but it does not reverse the completed T9 state change.
Requesting revocation earlier in wall-clock time would not by itself change this supplied accepted order. The evidence needed is the effective sequence in the system whose gate is being checked.
Variation F leaves the role active but supplies an independently authorised intervening edit that advances R7 to revision 5 with label L2 before T9. T9’s expected-revision-4 condition then fails. R7 remains L2, revision 5. A’s proposal may have been reasonable when prepared, but its application precondition is no longer satisfied.
F is a stale-state failure, not necessarily an AI reasoning failure or a cryptographic problem. An accurate reconstruction names the failed condition rather than blaming every unsuccessful result on the model.
Across D, E and F, the signed operation can be the same while execution context changes the outcome. An action report must therefore connect the proposal to the state and rules at execution.
Back to contents · Next section
7. Correct a completed effect without rewriting history
Suppose the baseline completed and H later decides the catalogue should show L0 again. A new, separately approved corrective operation is executed against revision 5. It sets label L0 and advances the catalogue to revision 6.
The current label now resembles the original label, but the history is different: revision 4/L0, then revision 5/L1, then revision 6/L0. The corrective action did not make T9 never happen. It is a new authorised event with its own evidence.
Now add a supplied external consequence: after time 6 and before the correction, a portal exported a copy of revision 5/L1. Updating the current catalogue or restoring A’s local checkpoint does not automatically retract that exported copy. A separate process would be needed to address the recipient and the earlier representation, if authorised and appropriate.
This is why reversibility needs a concrete boundary. Local model state, gateway queues, current application state, retained history and external copies are different objects. A control that restores one does not necessarily restore the others.
No real portal or recipient is involved here. The example simply prevents the phrase “rolled back” from claiming more than the stated corrective operation achieved.
Back to contents · Next section
8. Read a receipt for what it actually says
At time 3, the node acknowledgement identifies T9. In the baseline it does not yet establish execution, application success or finality. At time 5, the supplied execution evidence and identified state show the catalogue change. At time 6, the independent finality check adds its separate assurance.
Ethereum’s JSON-RPC documentation distinguishes a transaction identifier from its execution receipt and states that receipts are not available for pending transactions. A receipt includes block identity and execution information. We use that narrow distinction as context, without turning a null response into proof of one universal failure cause. Ethereum JSON-RPC documentation
A gateway receipt can also have a different scope. “Request accepted by G” might mean only that G queued a request. In this exercise, the time-2 evidence expressly says G signed and submitted, while the time-3 node acknowledgement comes from the next boundary. Their meanings are supplied separately.
A model’s prose summary is another evidence item. If A says “the catalogue is updated” at time 2, that claim is premature against the baseline trace. The appropriate report then is that the operation was submitted and its effect remains unverified.
Back to contents · Next section
9. Reconstruct attribution without inventing hidden intent
A complete trace links H’s exact approval, A’s proposed fields, G’s checked payload, T9’s identity and the accepted application effect. These links support an account of which controlled path produced the operation.
They do not reveal every internal reason the model generated its proposal. A ledger entry cannot prove that A understood H’s purpose, that its explanation was truthful or that it would behave safely under a different prompt. Those are separate claims requiring relevant evidence.
The opposite inference is also weak. A late effect after a successful stop does not by itself demonstrate secret persistence or resistance to correction. Our baseline explicitly explains the effect through an already submitted operation. A different incident might contain evidence of another path, but it must be established rather than invented.
For a useful incident review, ask which handoff occurred, which authority covered it, what evidence binds the payload, which gate was still active and what was observed afterward. This is more precise than attributing the entire distributed workflow to one conversational sentence from the agent.
Back to contents · Next section
10. Exercise: identify the resulting state
All variations reset to the initial state unless stated otherwise.
- Baseline: A stops at time 4 after submission; T9 executes with active role and revision 4. What is R7 after time 6?
- B: no request reaches G before the stop. What is R7?
- C: signed bytes remain solely inside the stopped gateway and are never submitted or exported. What is R7?
- D: effective role revocation precedes T9. What is R7 under the toy rule?
- E: T9 precedes effective role revocation. Does later revocation restore L0?
- F: an intervening edit has already created revision 5/L2. Does T9 change it?
- After the baseline, the approved correction returns label L0 at revision 6. Has the exported revision-5 copy automatically disappeared?
Answers and reasoning
- L1, revision 5, with A stopped. The earlier operation remained executable.
- L0, revision 4, under the explicit no-submission-path assumptions.
- L0, revision 4, under the stronger sole-copy and no-export assumptions.
- L0, revision 4. T9’s application-role condition fails before mutation.
- No. R7 is L1, revision 5; revocation constrains later role-dependent operations rather than undoing the completed one.
- No. The revision precondition fails, leaving L2, revision 5.
- No. Current state correction and external-copy retraction are separate effects.
An additional evidence question: does T9’s identifier alone prove H approved its exact contents? No. That conclusion requires the linked approval and payload-checking evidence supplied elsewhere in the trace.
Back to contents · Next section
11. Write an outcome report with the right scope
For the baseline, write: “H approved the specified R7 update. G checked and submitted the matching operation, acknowledged as T9. A was stopped before execution and made no later proposals. T9 subsequently executed under the still-active application role, producing revision 5/L1; the identified state and finality condition were independently checked. The stop did not retract the earlier submission.”
For D, write: “The operation was submitted, but the effective role revocation preceded its execution. Under the application’s supplied rule, no catalogue mutation occurred.” For F, name the stale revision instead of claiming that revocation blocked it.
These reports preserve the distinction between human authority, model proposal, gateway action and external effect. They also identify what was verified rather than implying that every system in the path was inspected.
A real deployment needs tested control boundaries, trustworthy evidence and a response appropriate to the consequences. This lesson provides a small reconstruction method, not a guarantee that any AI system will remain controllable or that a blockchain makes its assertions true.
Back to contents · Next section
Frequently asked questions
Does stopping an AI cancel its pending blockchain operations?
Not automatically. The result depends on what has already left its control and what execution gates remain effective.
Is a transaction hash proof of completion?
No. It identifies an operation. Execution, intended application effect and relevant finality need their own evidence.
Can a later correction restore the current value?
Under a defined authorised procedure, yes. It does not make prior execution or external copies disappear.
Does the chain prove the AI’s intent?
No. The trace can support action attribution and recorded effects, but not every claim about internal reasoning or future behaviour.
Back to contents · Next section
Sources and further reading
Primary sources checked on 12 October 2026:
- NIST AI Risk Management Framework 1.0: January 2023; documented oversight and component-level risk responsibilities.
- Ethereum JSON-RPC documentation: transaction and receipt distinctions. No live request, deployment or transaction is part of this exercise.
For the wider AI-control problem, read Corrigibility, Shutdown and Replacement. This lesson’s distinct contribution is the exact proposal-to-effect trace, including the two accepted revocation orders and the limits of correcting a completed catalogue update.