The Payment Registry.
A mechanism for the due file of maturity.

A record is not a count. A receipt is not proof.

Every user holds a certificate. Every issuer holds a security. In any dispute over a financial obligation, a lease, a loan, a finance payment, a structured Murabahah, the question is never "did a payment happen?" It is "how many payments remain, and against which evidence?"

The conventional answer is to count by hand. Pull the contract. Match the certificates. Adjust for the reschedule, the partial, the commission, the deferred service fee. The answer takes hours and is provisional. Both parties leave the room with a different number.

The Payment Registry replaces the count with a declaration. Each payment is declared once, against a sealed evidence hash, and the registry decrements the remaining series automatically. The number you see is the number the registry will defend.

Terminology of the file.

The registry inherits the vocabulary of finance and uses it strictly. Where conventional usage is ambiguous, the registry's usage is the operative one.

A note on Lease and Rent.

Two relations. Two horizons. Lease, an asset for a known annuity, returned at the end. Rent, an open tenancy, paid month after month, with no horizon to close. The registry survives either. But only lease can be sealed as a finite series. Rent runs forever, and forever is not a number.

A note on Commission and Ujrah.

Two ways an asset earns a return. Two names for them. Commission, a percentage on the asset. Variable. Expressible against the total. Capable of compound logic. Claimed once at maturity, but pre-defined from day one. Ujrah, a flat fee. Declared at signing. Paid up-front. Indifferent to the size of the transaction. The registry treats them differently in only one place, the amount due (§ VII). Both must be pre-defined. Neither may surface after the fact.

One source of truth per rule.

One registry per user. The Payment Registry observes the rule of a single source of truth without exception. Principle 7 of the CTinFold corpus binds it.

Each user holds one registry. That registry is not shared with any other user. It is not derived from any other file. It does not delegate its logic to the wider code path. The registry is the only object in the system that decides whether a series of payments has decremented.

The registry does not exist until the user declares a relation that requires it. A one-off transfer, a cash settlement, none of these create the registry. Only an eligible relation, declared against an issuer, with a stated annuity and a stated series of payments, brings the registry into being.

Signal protocol

On declaration, the registry asks one diagnostic. Is this declaration receivable in full for Actor 2? If yes, the obligation is treated as cleared at maturity and the file proceeds without a residual count. If no, the registry asks the next question, and only then does it reveal itself to the user. How many payments remain, including this one? The user answers. The registry seals.

The three actions.

Once an obligation is sealed, every subsequent declaration against the same issuer must take one of three forms. The registry permits no fourth path.

Each action carries a single rule the registry will not waive. One source of truth per rule, one payment per declaration. If a user wishes to declare two payments, two declarations are required. The registry does not aggregate.

Determination of the registry and the verdict.

When new evidence is appended to an obligation, it does not enter freely. The validating verdict, CTinFold's policy, applies six ceiling rules to determine whether the appended set is admissible. The rules are stated below in the form the verdict evaluates them.

The asymmetry between 6C and 6J is deliberate. The registry permits an obligation to grow. Users frequently extend a lease, restructure a loan, expand a finance arrangement. But it does not permit an obligation to silently shrink. Downward revision must pass through minus one.

Commission and Ujrah. Four conditions only.

The registry asks the commission-or-ujrah question on exactly four occasions. Anywhere else, the question would invite a user to attach a fee retroactively. And the registry's first principle is that no value enters the record after the fact.

The amount due. Why the third payment is the first reliable one.

The amount per payment is not surfaced to the user immediately. It cannot be. The first payment may carry a commission or an ujrah, and the registry has no way of knowing, at the moment of sealing, whether that fee was included or paid separately. The second payment is the first clean attempt, but a clean attempt is not yet confirmed.

On the third payment, and only on the third, the registry exposes the amount-per-payment field and binds the obligation to it. From there, the amount is enforced. A declared amount that diverges from the third-payment amount is treated as an exception and routed through the append path.

Sealed evidence and the hash chain.

Every obligation in the registry is identified by the triple hash(relation + provider_id + evidence). The first two arguments fix the actor and the kind of obligation. The third, the evidence itself, fixes the obligation uniquely. Two leases between the same actors are not the same obligation. Their evidences differ, and so do their hashes.

The hash is also the registry's defense against tampering. The evidence value is stored in two forms. evidence_hash for identity. evidence_raw for regulators and auditors. Any deviation between the two on read is a failure the registry surfaces, not a discrepancy it absorbs.

This is the Payment Registry root hash sealed on the fourteenth of May, twenty twenty-six. Two hundred and five files. Twenty-eight directories. Four point one megabytes. Zero failures. The hash above is the proof that every byte of the registry as it stood at that moment can be reconstituted byte-for-byte. And that any byte that has since drifted is no longer the due file of maturity.

A worked example.

A partner holds a loan obligation toward a counterparty. The first declaration seals the evidence. Two payments later, the partner takes a second loan from the same actor and declares a wholly new security. Then it reschedules the first.

At every step the registry knows three things at once. Which actor. Which obligation. How much of the series remains. At no step did the registry derive a count from another file. The count is the registry's own.

Closing.

The Payment Registry is a sealed mechanism, proven by hash and not by claim. It counts the remainder of a series of payments against a sealed evidence, one user at a time. It does not do interest. It does not do reconciliation. It does not summarise. What it offers is the one number every financial dispute eventually arrives at, available on demand, sealed cryptographically, and verifiable by the other side through hash proof alone, without ever exposing the registry itself.

This is, in the end, the whole claim of CTinFold. A financial obligation, once declared, can be carried forward through payments with its proof intact. The Payment Registry is the place where that claim becomes operational.