Abstract

A distributed ledger must agree on an event-dependent trade even when evidence arrives unevenly and a payment provider has completed only part of the transfer. The participants need one record of the accepted event, the trades it permits, and the performance still owed. We construct a protocol that commits this complete execution state while allowing unresolved events and payments to remain explicitly pending. A confirmed parent block fixes the encrypted transaction order before decryption, so participants can collect event evidence while revealing instructions whose positions are already fixed. Closed collections of signed evidence let the participants agree despite missing responses. Under the stated fault, cryptographic, availability, and adapter assumptions, we prove agreement, atomic ledger updates, conservation, and progress without waiting for every external action to finish. Actual settlement additionally requires authority, funding, and provider performance. We also prove a five-round bound for a specified class of protocols that establish two separate ordering-related certificates at the same height. The parent-fixed construction lies outside that class.

BFT abbreviates Byzantine fault tolerance: agreement despite participants that can send false or inconsistent messages.

The author has a commercial interest in systems of the kind this paper describes.

1 The Governing Problem

Four participants keep copies of a ledger. Alice has instructed it to transfer seven units to Bob if an external event resolves yes. Some participants may receive the event report while others still await it. One participant may send false reports or inconsistent messages. The honest participants must agree on both the event decision and the transfer before changing their copies. A missing report must have a defined result if other work is to continue.

The participants are called validators. A participant that can deviate arbitrarily is called Byzantine. Byzantine fault tolerance (BFT) asks honest validators to maintain agreement despite a bounded number of such faults. Here agreement concerns the full execution of a trade: the accepted event, the clearing decision that determines what each party owes, and the resulting performance or outstanding obligation. A local transfer changes balances within the ledger. An external transfer requires a provider to act outside it.

The external case adds a different uncertainty. A command for 100 units may have produced confirmed performance of 60 while the remaining 40 remains possible. Recording zero would discard completed performance. Sending a fresh command for the unpaid amount could duplicate performance if the first command completes. The ledger must retain the 60, the remaining obligation, and the first command’s possible further effect. Later evidence can then support completion or an authorized recovery attempt. An instruction receipt records what the ledger did with an instruction. It can confirm admission of an external plan while that plan still awaits settlement.

There is also an ordering problem before execution. A validator that reads a pending trade before its position is fixed can insert a transaction before it. Threshold encryption divides decryption power among validators, so fewer than a specified number cannot reveal fresh protected terms. The protocol must therefore specify when honest validators release their decryption contributions, called shares. This construction fixes the encrypted order in the preceding confirmed block. Decryption and event collection can then proceed concurrently. A block’s height is its position in the ledger sequence. The preceding block is its parent, and the next block is its child.

These difficulties require separate arguments. Evidence collection must produce a finite, checkable input despite missing messages. Agreement must select one such input without losing safety when a leader or communication path fails. Execution must preserve completed effects and unpaid obligations as providers respond. Agreement on an instruction alone establishes none of its external performance. The child therefore commits all three results under one state root, a cryptographic hash that binds the complete recorded state. A certificate is checkable evidence for a particular protocol claim. Its meaning depends on the statement its signers authenticate.

Practical Byzantine Fault Tolerance established agreement over replicated state-machine execution [5]. Here a state machine is a rule that computes the next ledger state from the present state and its admitted inputs. Narwhal separates transaction dissemination from ordering [8], and F3B releases threshold decryption material after transaction confirmation [11]. The remaining construction problem is to combine fixed encrypted order, incomplete event evidence, and continuing external execution in one reproducible state transition. The proofs below use an existing agreement protocol and specify the additional values and evidence that it must accept.

Admissible Obligation Transitions defines event atomicity and the choice among gross, net, and provisional obligations [1]. Here event atomicity means that the accepted outcome and its clearing and execution dispositions enter the ledger together. Each cleared external group carries its command plan, known performance, outstanding obligations, and continuation. Legal discharge follows the configured performance rule and its institutional basis. Beneficiary receipt requires the corresponding authenticated evidence.

This paper uses ledger confirmation for the protocol’s committed decision. Legal finality is the point defined by applicable rules and law. Funding supplies the required settlement asset on the clearing architecture’s specified clock [2]. Beneficiary receipt is the receipt of usable value. These events can occur at different times. Principle 8 of the Principles for Financial Market Infrastructures (PFMI) requires rules defining when settlement is final [22]. Fedwire illustrates the distinction: Regulation J and Operating Circular 6 determine finality for its payment orders [23, 24]. Another ledger cannot confer that finality.

The results concern components that implement the custody, encryption, event admission, deterministic execution, and consensus interfaces specified below. The later allocation construction makes one execution obligation explicit: compatible received quantities must serve as much admitted outstanding performance as the fixed history permits. The history analysis then distinguishes fresh hidden instructions from disclosed ones, and first completion from current performance after a reversal.

2 Model and Types

The fault bound determines how many signatures a decision needs. A quorum is a sufficiently large set of validators that any two such sets share an honest participant. That shared participant prevents incompatible certificates when honest signers obey the protocol’s voting rule. Write \mathcal{V} for the validator set, n for its size, f for the permitted fault count, and q for the quorum threshold.

The strict formula matters when 3 divides n. For example, q(3k)=2k+1, whereas \lceil2(3k)/3\rceil=2k is too small for the claims below.

The construction separates safety, which excludes conflicting decisions, from liveness, which requires an eventual decision. Arbitrary message delay permits the former. The latter requires communication eventually to recover. An encryption epoch is an interval governed by one declared key record and fault roster. The static adversary assumption fixes corrupted participants within that epoch.

Encryption must allow honest validators to check a decryption share without learning the plaintext too early. We use the named threshold-encryption scheme TDH2 for this interface. A label binds a ciphertext to its intended public context. Distributed setup supplies each validator’s secret share and a public key for checking that validator’s later contribution. The reconstruction threshold k is the number of distinct valid shares needed. The cryptographic assumption below names its security model: decisional Diffie–Hellman is the underlying computational hardness assumption, and random oracles model the specified hash interfaces.

An instruction must expose enough information to begin event collection and select a settlement rule while keeping its economic terms encrypted. Authentication identifies who authorized those public fields and the encrypted payload. A decision clock specifies which clock determines the last permitted instruction decision. The hash function \mathsf{H} binds canonical bytes: canonical means that each admitted value has exactly one encoding.

The concrete profile separates two jobs. A fresh session key encrypts the instruction payload with authenticated encryption, which both hides its contents and detects changes. TDH2 encrypts that session key for threshold reconstruction. Its encrypted key is called the capsule. P-256 names the elliptic-curve group, SHA-256 the hash function, AES-256-GCM the authenticated-encryption scheme, and Ed25519 the signature scheme. A nonce is the fresh per-encryption value required by the payload scheme. Write PK for the threshold public key and m for the plaintext instruction. The type symbol \sqcup separates tagged alternatives, so a failed authentication remains an explicit result.

Confidentiality compares what an attacker sees for two candidate instructions with the same visible metadata and length. Indistinguishability means that efficient computation cannot reliably tell which candidate was encrypted. A security game gives the attacker one encryption of one of two candidate messages, called its challenge ciphertext. The permitted decryption interface answers other queries. It excludes the challenge ciphertext and requests equivalent to that same labeled object. The following reduction changes one encryption component at a time, bounding the whole profile’s advantage by the named primitive guarantees.

A proposal can name stored instructions without carrying their complete bytes. A batch body holds those instructions in order. Its short descriptor binds that body and its admission limit. Later retrieval is called materialization. This transport choice requires both unique names and continuing custody, which the next section establishes.

Two identities serve different purposes. An instruction identifier detects a repeated request. An occurrence key names one position in one admitted batch. Receipts must retain the position even when a repeated request is rejected.

The replicated state must retain instructions and their continuing consequences. An allocation attributes a received quantity to a particular obligation. A plan records an external group’s commands and recovery rules, while an outbox records admitted commands awaiting dispatch. A reservation sets aside funded resources for that work. The state coordinates below keep these records distinct. A partial map may leave keys undefined. An injection assigns distinct values to distinct keys.

For each height h, write S_h for the confirmed state, R_h for its complete transition root, and B_h for the block that carries that transition. The subscript h-1 identifies its parent. The complete root formula appears with the block function after its component inputs have been defined.

3 Custody Before Ordering

Large transaction bodies need not travel in every proposal. The proposal can order short descriptors if consensus has an independent reason to know that the named bodies can be retrieved. Narwhal made this separation explicit for a mempool organized as a directed acyclic graph (DAG) [8]. A mempool holds transactions awaiting order. The graph records their dissemination dependencies. The Aptos white paper specifies quorum-signed proofs of availability for stored batches, and its Quorum Store uses certified batch references on the consensus path [9, 10]. The certificate used here is strictly a custody certificate.

Custody answers whether a named body remains available. The parent must separately fix where that body’s instructions will execute. The next object, called the ordering witness, is the ordered descriptor list committed by the parent. Its role is to make the child order independently checkable.

An admission deadline ends the opportunity to order a descriptor. It cannot end storage or decryption service for a descriptor already ordered. A partition could otherwise leave the child with a binding order but no way to execute it. The following fences are certified conditions that permit an obligation to end or transfer. They distinguish new admission from continuing service.

A retained instruction may reach its decision after its own authority expires. The child still needs a valid terminal result. The decision rule therefore uses evidence about the decision time to choose execution, expiry, or uncertainty. A terminal result ends this instruction occurrence while preserving any existing external plan.

4 Parent-Fixed Order Before Plaintext

Let \mathsf{LC}_{h-1} be the ledger-confirmation certificate for B_{h-1}. The certificate fixes both the parent state root and \mathsf{H}(W_h). The epoch key is stable across views, so a view change does not strand a ciphertext.

A view is one leader attempt within the agreement protocol. Changing views may replace a leader, but it must preserve the previously fixed order. Share release also needs persistent memory: restart or retry must return the original authorized response instead of assigning the same ciphertext elsewhere. The release context below binds the chain, key, parent, and occurrence.

A security parameter controls the cryptographic instance size. An advantage is negligible when it decreases faster than every inverse polynomial in that parameter. The four conditions below separate cryptographic secrecy from the protocol rule that authorizes release.

5 Event Collection

The event agreement procedure is called Event-Collect (EC). Different validators can hold different event reports when collection closes. Waiting for every report would let one silent source prevent progress. Each validator therefore signs a finite snapshot of its admitted evidence. An agreed collection of snapshots determines either an accepted answer or a reason to defer each relevant event. Deferral lets unrelated work continue.

The event candidate set contains the unresolved events needed by the already ordered instructions. For event e, \Omega_e is its allowed outcome set. Acceptance carries evidence for an outcome. Deferral carries a reason, a resumption tier, and a negative witness: the checked failure or signed collection close. Such a witness establishes the recorded decision basis, including uncertainty. The five tiers T_0 through T_4 require raw evidence, authentication, corroboration, collateral, and agreement, respectively.

The parent state and the public event identifiers in the materialized bodies named by W_h determine a finite candidate set \mathcal{E}_h: every referenced event that has no accepted outcome in S_{h-1}^{\mathrm{event}}. A previously deferred event remains unresolved. An accepted event keeps its recorded outcome. The leader cannot add or omit a candidate. The configured collection deadline closes finite evidence snapshots. Byzantine agreement then selects one complete package and returns one label for every member: L_h(e)\in \{\mathsf{accept}(o,C_e):o\in\Omega_e\} \cup\{\mathsf{defer}(r,k,N_e):r\in\mathsf{Reason},\ 0\le k\le4\}. An accepted label carries a canonical outcome-evidence certificate C_e that has passed tiers T_0 through T_3. The Event-Collect commit proof elevates that object to T_4. A deferred label carries the reason, the tier at which evaluation resumes, and a canonical negative witness N_e. That witness records the checked inputs and either the failed predicate or the quorum-signed close of the event deadline. It does not represent absence as proof.

The outcome o is the reported answer to the event query. The label L_h(e) is the protocol decision to accept that answer or defer event-dependent execution. An accepted label determines protocol execution; it does not by itself establish the answer’s legal effect outside the governing rules and law.

Authentication proves who sent a report. Corroboration applies the event’s rule for combining sources. A committee is one possible rule: its threshold must prevent incompatible certified answers while leaving enough honest members to certify a common answer. Committee faults and thresholds are separate from the ledger’s validator fault bound.

6 One Event-Atomic Ledger Transition

Return to the command for 100 units that has produced 60. Its observation must enter the ledger even if a later instruction is rejected. The ledger can then attribute the received 60 to the obligation while retaining the unpaid 40 and the command’s possible further performance. A replacement requires evidence that releases enough of that remaining command capacity. Money available to fund a replacement is a separate condition.

A local transfer can apply all balance changes in one ledger update. An external provider supplies its own observations and performance guarantees. An adapter states how the ledger checks those observations and interprets the provider’s commands. The next definitions make that contract explicit, then assemble collection, clearing, and plan progress into one block function. The function computes without external input/output (I/O), so every validator and later verifier can reproduce it from the recorded inputs.

Clearing converts an admitted instruction and its event outcome into a group of transfer obligations. Write Z for the current working ledger state and G for one such group. A leg is an individual transfer within the group. The symbol \bot means that an event-free instruction needs no event outcome.

If clearing nets obligations, configuration names the eligible classes, parties, netting rule, and governing foundation. Otherwise it produces gross legs. Arithmetic cancellation alone supplies no legal discharge.

An adapter’s terminal witness is the evidence required to establish a claimed completed result. A provider’s idempotency contract specifies how repeated delivery of the same command avoids duplicate effects. Its status-query contract specifies how the dispatcher obtains evidence about that command. Authority at use requires permission when the external act actually occurs.

A request, an external occurrence, and an observation about that occurrence need distinct identities. A retry retains the command identity. The provider idempotency or authoritative reconciliation contract establishes effect uniqueness. Observing an occurrence twice records the same physical payment. A plan relates these identities to the obligation and the recovery procedure.

Before the command has closed, part of its requested performance may still occur. Call that remaining possibility its command exposure. For obligation o, write Q_o for required quantity, A_o for effective allocated performance, and U_o for outstanding performance, with Q_o=A_o+U_o. The next rule reserves performance capacity across every plan serving that obligation. It prevents separate recovery attempts from each treating the same unpaid amount as available.

For the 100-unit command with 60 recorded, the outstanding obligation is 40. If that command can still produce 40, the new-command bound permits zero. Suppose an authoritative closure confirms total realized performance of 60 and reduces further possible performance to zero. The remaining capacity is then 40. With the required authority and funding, a replacement can serve those 40 units. Recording its final performance reduces the outstanding obligation to zero. The plan settles when its other obligations are discharged and all command exposures have resolved dispositions.

An authenticated occurrence supplies a physical quantity. An allocation records which obligation that quantity satisfies. Cash availability answers whether resources can fund another action. These are different accounting questions: a past payment remains in history even when a later reversal changes current performance or available cash. A reconciliation hold preserves the historical allocation’s owner while its support is in question.

Provider facts can change an admitted plan without any new instruction from its original sender. A continuation specifies that plan’s next permitted operation. The progress function updates every admitted continuation subject to resource, authority, and exposure checks, then records what remains to be done.

The child needs one evidence input for time decisions, provider observations, and local transfer checks. These inputs have different sources and roles. The provider fact collection uses the same finite-snapshot method as event collection. The child decision itself selects that fact union.

Two receipt types follow from this separation. An instruction receipt records one terminal instruction decision, including external-plan admission. A progress receipt records a later change to an existing plan. In the instruction tuple below, s is status, d the clearing decision, and u the disposition. The type alternatives preserve those three answers even when a branch performs no local transfer.

The instruction step checks rejection conditions before creating an effect. Total means that every admitted input has a defined result, including failed authentication, replay, expiry, and uncertainty. This property lets the child finish processing its fixed order when an individual instruction fails.

The whole block first records independent provider facts, then processes the ordered instructions, and finally advances continuing plans. The function works on private intermediate copies. Only its final state becomes a public root. The next ordering witness enters that same state, binding this block’s result to its child’s future encrypted order.

Some instruction work can execute in parallel after its inputs are fixed. A step’s footprint includes every mutable coordinate it reads or writes. The following sufficient condition permits swapping two successful steps without changing their result.

7 Consensus Construction

The execution rule now supplies a complete candidate state. Consensus selects one such value and preserves its decision through leader changes. A quorum certificate collects the protocol’s required votes over one statement. The symbols \Pi_{\mathrm{BFT}} and \Pi_{\mathrm{EC}} name the child and event agreement instances, respectively. Their separate signing contexts prevent a vote for one purpose from authorizing the other.

Let \Pi_{\mathrm{BFT}} be a HotStuff-family replicated-state-machine protocol with authenticated proposals, quorum certificates, safe view change, and an external validity predicate [6, 7]. The construction does not alter its locking proof. It changes the value admitted by the validity predicate.

Each child height runs the bound Event-Collect instance before proposing its complete execution root. After parent confirmation, materialization, decryption, event snapshots, and provider-fact snapshots proceed concurrently where their dependencies permit. The child waits for a complete event decision, decryption, and a finite fact closure. It never waits for every provider to finish. Pending observations produce valid continuation states. The Event-Collect and child-block instances use distinct signing contexts.

The four certificate roles can now be compared. A custody certificate concerns stored bytes. The parent confirmation binds order. The event certificate binds the event decision. The child confirmation binds the resulting ledger state. External dispatch requires the last of these and authority at use.

Ledger progress can commit a pending plan. Completion of that plan needs additional premises about the provider and the permitted recovery sequence. A well-founded progress rank is a measure that strictly decreases on the specified terminal transitions and cannot decrease forever. It makes the required finite progress toward settlement an explicit assumption.

8 A Five-Round Bound for Same-Height Locks

The construction moves its ordering lock to the parent. The value of that move is clearer after considering protocols that first establish the lock at the target height.

The bound is not universal. A protocol that uses one certificate for both availability and ordering removes one causal cut. A protocol that ledger-confirms before execution removes the share-to-confirmation dependency. Each protocol then lies outside \mathcal{P}_{\mathrm{DC}}. The parent-fixed construction also lies outside the class: \mathsf{LC}_{h-1} supplies the ordering lock before the target-height proposal, so decryption can overlap Event-Collect.

9 Replay and Finality Boundaries

A later verifier should reproduce the confirmed decision using retained records. That procedure is called replay. Its input must include the original rules and evidence, including failed and pending branches. A live provider query would make the answer depend on when replay occurs, so replay uses only recorded observations.

10 Security Budget and Capacity Boundary

Cryptographic thresholds state how many participants an attack needs. They do not state what corruption costs. The economic requirement must therefore remain a configuration condition.

A slashable stake is capital that the declared rule can actually forfeit for a proved signing violation. Open interest is the value of outstanding event-linked positions. The factor \gamma>1 specifies the required margin above that exposure. The following budget first combines identities under common control. It then compares exposed capital with the event-linked positions that conflicting confirmation could affect.

Economic independence is an admission assumption, not a fact proved by distinct keys or balances. A deployment must establish beneficial control outside the protocol and aggregate disclosed affiliates before forming the roster. If it cannot do so, B_{\mathrm{sec}} is only an upper bound on independent slashable capital.

The condition must hold through the full epoch, including after price moves, stake exits, and slashing. If it fails, new event-linked exposure is not admitted. This is a bound on slashable capital, not a proof that every adversary has negative expected value. Off-system gains and unenforceable slashing can invalidate the economic interpretation without changing the BFT threshold.

Early decryption requires k shares. An adversary that already controls f validators needs k-f additional shares, equal to n-2f at k=q. The incremental bribery cost depends on the least compensation those honest share holders accept; it is not equal to their posted stake unless loss of that stake is certain and enforceable.

A fast stream of pending receipts can coexist with slow external completion. The throughput measure must therefore count the completed object once and name its completion condition. The later history analysis separately measures current performance after any reversal.

For a stable operating regime in which the long-run limits exist, write \lambda_{\mathrm{succ}}= \lim_{T\to\infty}\lambda_{\mathrm{succ}}(T). Measure every stage rate in completed instruction-equivalents per unit time. Let \lambda_{\mathrm{instr}} be the sustained rate at which authenticated instructions pass semantic admission. Let \lambda_{\mathrm{event}} be the sustained rate at which event-linked instructions obtain accepted event labels. For custody, \lambda_{\mathrm{cust}} counts instructions in newly certified bodies, not batches. Let \lambda_{\mathrm{dec}}, \lambda_{\mathrm{exec}}, and \lambda_{\mathrm{persist}} be the sustained rates of plaintext reconstruction, completed execution, and durable instruction and progress-receipt persistence. If C_{\mathrm{block}} is the maximum number of successful instructions per block while T_{\mathrm{confirm}} is the sustained mean time between ledger-confirmed blocks, then \lambda_{\mathrm{succ}} \le \min\left\{ \lambda_{\mathrm{instr}},\lambda_{\mathrm{cust}}, \lambda_{\mathrm{dec}},\lambda_{\mathrm{exec}}, \lambda_{\mathrm{persist}}, \frac{C_{\mathrm{block}}}{T_{\mathrm{confirm}}} \right\}. If \lambda_{\mathrm{succ,event}} counts only successful event-linked instructions, then \lambda_{\mathrm{succ,event}} \le \min\{\lambda_{\mathrm{succ}},\lambda_{\mathrm{event}}\}. Event-free instructions do not pass through event admission and therefore do not enter the second bound. For external plans, an additional throughput bound includes provider completion, observation delivery, funded capacity, and fair continuation. Counting plan admission as external settlement would violate the definition. These inequalities are accounting bounds, not measured benchmarks. Moving bodies off the proposal path does not remove authentication, decryption, execution, persistence, or ledger-confirmation work.

11 Certified Compatible Allocation

The block function requires an allocation that all validators can reproduce. Conservation bounds how much performance can be used. Compatibility determines which obligations that performance can satisfy. Among the feasible allocations, execution should complete as much admitted performance as the closed evidence permits. The following example shows why an arbitrary fixed order is insufficient. Consider two occurrences a,b and two obligations x,y, each of one unit. The compatible pairs are (a,x),(a,y),(b,x). Assigning a to x conserves every quantity but leaves b without a use. Assigning a to y and b to x completes both obligations. The choice of a canonical order alone does not resolve this distinction.

A flow network represents quantities moving from available occurrences to compatible obligations. Each edge has a capacity, and each intermediate vertex passes on exactly the quantity it receives. A cut separates the source from the destination. Its outgoing capacity bounds every feasible flow across that separation.

We use the classical flow–cut relation [27] to separate the search for an allocation from the verification of its value. A second family of cuts fixes the choice among equally valuable allocations. Both certificates refer to the same admitted ledger snapshot.

The current U_j already accounts for effective fixed performance. Thus the construction subtracts fixed slices from supply and uses U_j directly as demand. A hold excludes supply without satisfying an obligation. Restoring its support follows the reconciliation rule before a new batch closes. Quantities in this construction are rational numbers in the declared unit. No conversion between assets follows from assigning them the same numerical value.

The source vertex s supplies the available performance, and the destination vertex t receives quantities assigned to obligations. The occurrence vertices are I, and the obligation vertices are J. This graph represents only the admitted compatible pairs. It creates no new permission to allocate.

Let C=\min\{\sum_i c_i,\sum_j d_j\}. Form a network with vertices s,I,J,t and arcs s\longrightarrow i\ [c_i],\qquad i\longrightarrow j\ [C]\ ((i,j)\in E),\qquad j\longrightarrow t\ [d_j]. Brackets give capacities. Every individual allocation is at most C, so the middle-arc capacity imposes no additional restriction. An allocation induces flow x_{ij} on each middle arc, its row sum on s i, and its column sum on j t. The flow value |g| is the total quantity leaving the source, equal to the quantity entering the destination.

A residual graph records permissible changes to a proposed flow. A forward edge permits additional use of remaining capacity. A reverse edge permits reducing an existing flow. Augmenting along a residual path changes each traversed edge by the path’s permitted quantity. A residual cycle can change the allocation while preserving its total value.

The cut also identifies a finite obstruction when some demand remains. In the two-occurrence example, the maximum value is two. If (a,x) is already a fixed legal allocation, only b remains available and only y remains outstanding. Their incompatibility gives additional value zero. A better unrestricted assignment supplies no authority to move the fixed slice.

Canonicality requires preserving total value while testing whether a coordinate can increase. A circulation is a flow adjustment with zero net change at every vertex. The proof uses residual circulations to characterize every such possible improvement.

An equal-value cut proves total optimality but does not certify this choice. For that purpose, retain the final induced flow g. For e_k=(i,j), remove both residual directions of e_1,\ldots,e_k. Call the remaining residual graph G_k(g). The removal fixes all earlier allocation coordinates and prevents a vacuous return along the reverse of e_k itself.

This proof gives a terminating construction. First find any maximum flow. For each e_k=(i,j) in order, augment along residual j–i paths and the forward arc i j. Stop when i j saturates or the return path disappears, then fix that coordinate. Each stage preserves the maximum total value. After rational scaling, each augmentation increases its coordinate by an integer amount, and that coordinate is bounded by C. Later stages preserve the established prefix optimum. The final flow therefore admits the cuts of Theorem 11.4. The reference uses breadth-first residual paths and exact rational arithmetic. The certificate checker reconstructs capacities and flows independently, then checks row bounds, column bounds, the total cut, and each prefix cut. The certificate contains at most m+1 vertex sets. Its verification uses O((m+1)|\mathcal A|) arithmetic comparisons, where \mathcal A is the network’s arc set. This count excludes the bit cost of rational arithmetic and input validation.

A signature or state hash alone supplies none of the compatibility facts. The institution’s admitted rules supply them, including any binding payer instruction and estate restriction. The certificate checks their mathematical consequences. Aggregate limits, seniority, mandatory lower bounds, indivisible lots, and all-or-nothing packages require a feasible-set construction that expresses those constraints. The bipartite theorem applies after that construction has been justified. A Boolean pair relation alone does not express them.

The preceding certificates identify a valid allocation. Durable application must also ensure that retries and competing requests cannot consume its physical quantity twice. A duty root is the stable identity of the obligation served by that quantity. The next realization retains fixed ownership as physical intervals and commits every change in one storage transaction.

12 Disclosure History and Effective Performance

An instruction carries a history before it enters a witness. Its effects continue after its first completed execution. The ordering theorem protects fresh hidden terms. Re-encrypting an already disclosed instruction cannot restore that condition. Similarly, the throughput measure counts a first completion even if some performance is later returned. The following analyses give each claim its explicit history.

A confidentiality game is an experiment that specifies what an attacker may observe and the two alternatives it must distinguish. The following game includes earlier disclosure and rejected submissions. A completion report likewise fixes the recorded history before it measures present performance.

13 Relation to Prior Work

Practical Byzantine Fault Tolerance (PBFT) established practical state-machine replication under Byzantine faults; the partial-synchrony model is due to Dwork, Lynch, and Stockmeyer [5, 4]. HotStuff gives a responsive linear-communication lineage, and HotStuff-2 shows that the underlying BFT problem admits an optimistic two-phase regime under its stated pacemaker and view-change design [6, 7]. This paper treats that consensus safety result as a consensus-protocol property. The five-round theorem concerns the added causal gates of a different, explicitly defined class; it is not a lower bound on HotStuff-2.

Narwhal separates reliable payload dissemination from ordering [8]. The Aptos architecture similarly pipelines transaction dissemination, metadata ordering, batch storage, execution, and ledger certification; its Quorum Store brings proofs of stored batches onto the consensus path [9, 10]. The custody certificates in this paper follow that lineage while keeping their semantic boundary explicit.

F3B applies per-transaction threshold encryption and releases decryption material after the underlying consensus ledger-confirms the protected transaction [11]. Here the parent ledger-confirms an encrypted child order, which lets child decryption overlap event collection. The result is narrower than general fair ordering: it prevents same-witness insertion conditioned on hidden plaintext.

An optimistic oracle admits an external report subject to a challenge process that can require adjudication. Bonded reports, disputes, and increasing appeal stakes are established in optimistic-oracle systems such as Augur, UMA, and Kleros [19, 20, 21]. The material added here is the consensus interface: one complete accepted/deferred label vector, recoverable agreement over closed evidence snapshots, acknowledged-evidence inclusion, a monotone floor, local deferral, and append-only correction after confirmation. External execution adds durable plans and explicit obligation conservation. These composition claims require implementation refinement and provider evidence.

The PFMI does not define a consensus protocol. Its principles on settlement finality, money settlement, and exchange-of-value systems identify the institutional distinction that the certificate table preserves [22].

14 Limits and Open Problems

15 Conclusion

The seven-unit trade requires a common event decision and a reproducible transfer result. External execution adds a continuing obligation: preserve what the provider has done and what remains owed. The construction meets these needs by recording one complete ledger transition, including valid pending and partial states. Local groups apply atomically. External plans retain their observed performance, reservations, and permitted recovery operations.

The parent fixes encrypted order before share release. Closed evidence collections then support agreement while decryption proceeds. Quorum-acknowledged evidence appears in every valid snapshot selection, while later evidence enters later contexts. Continuing custody and epoch service preserve admitted work through a partition. Explicit decision clocks provide terminal expiry or uncertainty branches when a fresh effect is no longer authorized.

Actual dispatch follows confirmation and authority at use. Replay reproduces the recorded computation without issuing commands. Compatible allocation maximizes new performance within its admitted snapshot and fixed history. Separate resource records preserve actual funding, and separate history measures retain both first completion and current performance after a reversal.

Ledger progress follows from the stated agreement, availability, timer, and bounded-execution assumptions. Settlement also requires funded resources and authority. Its progress depends on provider performance, observation delivery, and fair continuation. The named cryptographic contracts and implementation refinements remain premises to establish for a concrete system. The five-round result concerns its specified same-height double-certification class. Event collection, provider execution, and recovery retain their own communication and latency costs. The fixed workload grid illustrates those dependencies under declared schedules. Production latency and economic parameters require their stated evidence.

References

[1] Raeez Lorgat. Admissible obligation transitions. Companion paper in this series, September 2026.

[2] Raeez Lorgat. AMM-aware central counterparty risk. Companion paper in this series, September 2026.

[3] Raeez Lorgat. Recourse. Companion paper in this series, September 2026.

[4] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony. Journal of the ACM, 35(2):288–323, 1988. https://doi.org/10.1145/42282.42283.

[5] Miguel Castro and Barbara Liskov. Practical Byzantine fault tolerance. In OSDI, pages 173–186, 1999.

[6] Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abraham. HotStuff: BFT consensus with linearity and responsiveness. In PODC, pages 347–356, 2019. https://doi.org/10.1145/3293611.3331591.

[7] Dahlia Malkhi and Kartik Nayak. HotStuff-2: Optimal two-phase responsive BFT. Cryptology ePrint Archive, Paper 2023/397, 2023. https://eprint.iacr.org/2023/397.

[8] George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. Narwhal and Tusk: A DAG-based mempool and efficient BFT consensus. In EuroSys, pages 34–50, 2022. https://doi.org/10.1145/3492321.3519594.

[9] Aptos Labs. The Aptos blockchain: Safe, scalable, and upgradeable Web3 infrastructure. Technical white paper, 11 August 2022. https://legacy.aptos.dev/assets/files/Aptos-Whitepaper-47099b4b907b432f81fc0effd34f3b6a.pdf.

[10] Aptos Foundation. AIP-106: Optimistic Quorum Store. Aptos Improvement Proposal, 2024. https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-106.md.

[11] Haoqian Zhang, Louis-Henri Merino, Ziyan Qu, Mahsa Bastankhah, Vero Estrada-Galiñanes, and Bryan Ford. F3B: A low-overhead blockchain architecture with per-transaction front-running protection. In AFT, LIPIcs 282, pages 3:1–3:23, 2023. https://doi.org/10.4230/LIPIcs.AFT.2023.3.

[12] Victor Shoup and Rosario Gennaro. Securing threshold cryptosystems against chosen ciphertext attack. In EUROCRYPT, LNCS 1403, pages 1–16, 1998. https://doi.org/10.1007/BFb0054113.

[13] Victor Shoup and Rosario Gennaro. Securing threshold cryptosystems against chosen ciphertext attack. Full paper, September 2001, Section 6. https://www.shoup.net/papers/thresh1.pdf.

[14] Sourav Das, Zhuolun Xiang, Lefteris Kokoris-Kogias, and Ling Ren. Practical asynchronous high-threshold distributed key generation and distributed polynomial sampling. In USENIX Security, 2023. https://www.usenix.org/system/files/usenixsecurity23-das.pdf.

[15] SmartContract Chainlink. TDH2 Go implementation. Commit e8ec0386b06cabb83843 d77ee3890c84a2168cfa. Pinned primitive source.

[16] David McGrew. An interface and algorithms for authenticated encryption. RFC 5116, January 2008. https://www.rfc-editor.org/rfc/rfc5116.

[17] Simon Josefsson and Ilari Liusvaara. Edwards-curve digital signature algorithm (EdDSA). RFC 8032, January 2017. https://www.rfc-editor.org/rfc/rfc8032.

[18] Rosario Gennaro, Stanisław Jarecki, Hugo Krawczyk, and Tal Rabin. Secure distributed key generation for discrete-log based cryptosystems. In EUROCRYPT, LNCS 1592, pages 295–310, 1999. https://doi.org/10.1007/3-540-48910-X_21.

[19] Jack Peterson, Joseph Krug, Micah Zoltu, Austin K. Williams, and Stephanie Alexander. Augur: A decentralized oracle and prediction market platform. Version 2.0, 2019. https://www.augur.net/whitepaper.pdf.

[20] UMA Project. UMA data verification mechanism: Adding economic guarantees to blockchain oracles. Technical white paper, 2020. https://github.com/UMAprotocol/whitepaper.

[21] Clément Lesaege, Federico Ast, and William George. Kleros short paper, version 1.0.7. Technical paper, 2019. https://kleros.io/whitepaper.pdf.

[22] Committee on Payment and Settlement Systems and Technical Committee of the International Organization of Securities Commissions. Principles for financial market infrastructures. Bank for International Settlements, April 2012. https://www.bis.org/publications/principles-financial-market-infrastructures.pdf.

[23] Board of Governors of the Federal Reserve System. Regulation J: Collection of checks and other items by Federal Reserve Banks and funds transfers through Fedwire. 12 CFR part 210, subpart B. Federal Reserve regulation page.

[24] Federal Reserve Financial Services. Operating Circular 6: Funds transfers through the Fedwire Funds Service. Effective 5 January 2026. Operating Circular 6.

[25] CLS and FNA. Reimagining same-day FX: Exploring the case for additional settlement cycles. ShapingFX report, 6 March 2025. CLS report page.

[26] Wenxin Du. Three myths about payment innovation. Panel remarks, Jackson Hole Economic Policy Symposium, 29 August 2026. https://www.kansascityfed.org/documents/18601/Du_JH_Panel_Remarks_to_Post.pdf.

[27] L. R. Ford, Jr., and D. R. Fulkerson. Maximal flow through a network. Canadian Journal of Mathematics, 8:399–404, 1956. doi:10.4153/CJM-1956-045-5.

[28] SQLite authors. Write-ahead logging. SQLite documentation, accessed 5 September 2026. https://www.sqlite.org/wal.html.