What is confirmed after the chain changes?
Separate a provisional report, a repeated delivery and a final transfer.
The question
A mock chain reports transfers to a test account. The account starts with 100 confirmed credits. The case credits each stable event ID once after finality. Pending credits appear separately.
| Amount (credits) | Chain status | |
|---|---|---|
| T1 | 40 | Provisional |
| T2 | 25 | Final |
The status comes from the current accepted chain view.
“What would you report as confirmed and pending?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Separate the balances
What would you do here? Open the move you’d make.
Report 125 confirmed and 40 pending.
The strong move. The case counts the 25-credit final transfer and reports the provisional event separately.
Report 165 confirmed because both transfers appeared.
Tempting, but it misses something. T1 has provisional status under the case rule.
See how a strong candidate says it
“The confirmed balance is 125. Another 40 is pending. The provisional report does not add to the confirmed balance.”
Why it works: The case counts the 25-credit final transfer and reports the provisional event separately.
Step 2: Check the event identity
What would you do here? Open the move you’d make.
Count each message as a separate transfer.
Tempting, but it misses something. Two messages can describe the same event ID.
Use the event identity and the current chain status together.
The strong move. The same event can be delivered again. A changed chain view can also change the provisional record.
See how a strong candidate says it
“I’d check the stable event ID and its status in the current accepted chain view.”
Why it works: The same event can be delivered again. A changed chain view can also change the provisional record.
Step 3: Update the chain view
The accepted branch supersedes the nonfinal block that contained T1. T1 is absent from the new history. T2 is delivered again under the same event ID. T3 for 15 credits is final.
What would you do here? Open the move you’d make.
Drop the provisional credit and count each final event once.
The strong move. The new history removes the provisional event. The repeated message gives no new credit.
Count both T2 deliveries and subtract T1 from confirmed.
Tempting, but it misses something. T2 is one event ID. T1 never entered the confirmed balance.
See how a strong candidate says it
“T1 leaves the pending balance. T2 counts once. T3 adds 15 confirmed credits. The new balances are 140 confirmed and 0 pending.”
Why it works: The new history removes the provisional event. The repeated message gives no new credit.
Step 4: Explain the change
What would you do here? Open the move you’d make.
Call T1 a reversal of 40 confirmed credits.
Tempting, but it misses something. The previous view kept T1 pending, so there was no confirmed credit to reverse.
State the three changes and the revised balances.
The strong move. That explanation keeps the user-visible status tied to the evidence for each event.
See how a strong candidate says it
“I’d tell the owner one provisional item disappeared, one delivery repeated and one new transfer finalized. The confirmed balance increased by 15.”
Why it works: That explanation keeps the user-visible status tied to the evidence for each event.
The answer, in short
- Decision
- Report 140 confirmed and 0 pending.
- Because
- T1 left the provisional history. T2 remains one final event. T3 adds 15.
- What would change it
- A later report with accepted chain evidence could change the status of another event.
Common traps
- Counting a provisional event as final.
- Counting repeated delivery as a second event.
Check your answer
- I kept the balances separate.
- I checked event identity.
- I used the current accepted history.
- I explained the status changes.
Last reviewed Nov 11, 2026