The Deposit Registry.
One balance that proves itself.
Two relations, accepted deposit and withdrawal, operate together under a single registry per institution. Every event is sealed and permanent. The balance is never stored as an opinion, it is computed from the sealed events themselves. This paper describes how a deposit account stays provable from its first dinar to its last.
A deposit balance in an ordinary system is a number someone maintains. It can be edited, and if it is edited, nothing objects. CTinFold does not maintain a balance. It records deposit and withdrawal events, seals each one, and derives the balance as arithmetic over those sealed events. Aggregate principal is the sum of every sealed deposit. Outstanding balance is that sum minus every sealed withdrawal. Because the balance is computed and not stored, it can never disagree with its own history. When it reaches zero, the account is settled. Every depositor is known. There are no anonymous deposits.
One registry per institution. One section per depositor.
Each institution that uses CTinFold holds a single deposit registry. Inside it, there is one section for each depositor. Every deposit and every withdrawal is filed under the depositor it belongs to, and once an event is sealed it is immutable. Nothing about a past event can be revised. The registry only grows, event by event.
The institution is always the declaring entity. It declares on behalf of the deposit event, and the depositor is always named. There are no anonymous deposits. A deposit whose owner is unknown is not a deposit CTinFold will seal, because a proof that cannot name its subject is not a proof.
The balance is arithmetic, not a stored number.
CTinFold computes two quantities for every depositor. The aggregate principal is the sum of all sealed deposit events. The outstanding balance is the aggregate principal minus all sealed withdrawal events. Neither is kept as a field that someone updates. Both are derived, on demand, from the sealed record.
Because the numbers are derived from sealed events, they cannot drift away from the truth. There is no version of the balance that is wrong while the events are right. The events are the balance.
Illustrative. Every row above is a separate sealed event. The balance column is derived, not entered.
Active until zero. Then settled.
A deposit section carries one of two states, and the state is decided by the outstanding balance, not by anyone's declaration. While the outstanding balance is above zero, the section is active. The moment sealed withdrawals bring it to exactly zero, the section is settled. Partial withdrawals are allowed at any time while the account is active.
Deposits and partial withdrawals continue to be sealed into the section. The balance is recomputed after every event.
The account is fully withdrawn. The sealed history remains permanent and provable, closed at zero.
A withdrawal that overshoots is a failure, not a rejection.
Suppose a withdrawal is declared for more than the outstanding balance. CTinFold does not treat this as a normal decline. It is not a verdict at all. A rejection is a decision the engine reaches after examining a declaration. A withdrawal that exceeds the balance never reaches that examination, because the system stops before adjudication and writes a failure artifact to disk. The two are genuinely different events, and CTinFold keeps them different.
The decision engine examined the declaration and returned reject. It is a sealed verdict in its own right, a decision the system made about a valid, examined request.
The system halted before any verdict, because the request could not proceed. A failure artifact is written to disk. The topology does not process it. It is recorded, not decided.
This distinction matters for audit. A rejection tells you the system considered something and said no. A failure tells you the system refused to even begin, and preserved the attempt anyway. Neither is a gap. Both are on the record.
The registry proves the document.
When an institution exports a deposit statement, the document is sealed like every other CTinFold export and carries an export hash in its footer. The balance shown is the derived balance at export time, traceable back through every sealed deposit and withdrawal that produced it. Anyone holding the document can recompute the hash and confirm the statement is the one the system produced, untouched.
SHA-256
Recompute to verify
this document is untouched.