Non-Custodial Atomic Multi-Leg (DVP/PVP) Settlement

Executive Summary

JIL Sovereign's settlement engine advances delivery-versus-payment (DVP) and payment-versus-payment (PVP) settlements through a deterministic lifecycle — received, validated, compliance-checked, accepted, ready, submitted, confirmed, final. Four properties distinguish how it handles multi-leg settlement specifically: each leg of a DVP/PVP settlement is screened independently, and a compliance denial on any single leg atomically fails the entire settlement, so no leg ever executes while its counterpart leg is blocked; a beneficiary-binding check is re-verified as a second, independent gate distinct from the settlement's original binding; the engine relays only a payment authorization the client itself already signed, refusing to fabricate or self-sign a payment when none was supplied; and the settlement fee is not calculated until the underlying ledger transaction has crossed a configured finality-confirmation threshold.

Problem Statement

Multi-leg settlement designs typically enforce atomicity only where it is easiest — at the smart-contract or ledger execution layer — while leaving compliance screening as a single check applied to the settlement as a whole, or skipped per leg entirely. Custodial settlement platforms compound the risk by having the platform itself sign on the client's behalf, creating a moment where the operator, not the client, controls the payment instruction.

Why Existing Solutions Are Insufficient

• Contract-only atomicity: smart-contract DVP/PVP designs guarantee that both legs settle together or not at all on-chain, but apply no independent, per-leg compliance screening before execution.
• Traditional correspondent-banking PVP: relies on internal bank controls rather than cryptographic non-repudiation of the payment instruction, with no per-leg compliance re-screening.
• Custodial settlement-as-a-service: the custodian signs the payment instruction on the client's behalf, introducing a custodial moment the client does not control.
• Fee-at-submission designs: a fee is charged as soon as a transaction is submitted, before it is guaranteed final, exposing the operator to reorg risk and clients to fees on transactions that may not ultimately settle.

Technical Architecture

Per-Leg Compliance Atomicity

For a DVP or PVP settlement, each leg is evaluated against the compliance-decision service independently, in order. The moment any leg receives a deny decision, evaluation stops and the entire multi-leg settlement is rejected — no leg is permitted to execute while a sibling leg has failed. A SIMPLE (single-leg) settlement runs one equivalent check.

Re-Verified Beneficiary Binding as a Second Gate

Before per-leg compliance evaluation even begins, the settlement's recorded beneficiary binding is independently re-verified. A binding mismatch rejects the settlement immediately, with the mismatch reason and binding hash recorded — this check is structurally distinct from, and precedes, the compliance evaluation gate.

Non-Custodial, Fail-Honest Payment Relay

When a settlement reaches the ready state, the engine resolves the client-signed payment authorization that must accompany it — the settlement-level authorization for a SIMPLE settlement, or the designated payment leg's own authorization for DVP/PVP. If no such signed authorization exists, the engine explicitly fails the settlement with a reason stating that it relays a client-signed authorization non-custodially and will not generate one, rather than fabricating a signature.

Finality-Gated Fee Assessment

Only once a confirmed settlement's transaction has accumulated confirmations meeting the configured finality threshold does the engine calculate the settlement fee, mark every leg settled, and assemble a settlement receipt — embedding the beneficiary-binding hash and its verification result — before flipping the settlement to its final state.

Prior Art Differentiation

Patent Claim