Cross-Domain Finality
1. ABSTRACT
Defines the conditions under which an obligation spanning two Settlement Domains is considered final, and how local and global finality relate to one another.
2. MOTIVATION
Because execution happens locally within a destination domain, a precise definition is needed for when an obligation crossing domains can be considered fully resolved from the network's perspective, not just the recipient's.
3. TERMINOLOGY
Local finality — reached on a valid Execution Witness. Global finality — reached once the exposure an obligation generated has cleared via netting or rebalancing.
4. SPECIFICATION
An obligation reaches local finality when its assigned HSC produces a valid Execution Witness (NIP-0015). It reaches global finality when the exposure it generated between origin and settlement domains has been cleared through netting (NIP-0005) or rebalancing (NIP-0008).
Recipient-facing guarantees depend only on local finality. Network solvency bookkeeping depends on global finality. Implementations MUST NOT conflate the two in status reporting surfaced to end participants.
5. INVARIANTS
Recipient-facing guarantees MUST depend only on local finality. Network solvency bookkeeping MUST depend only on global finality. The two MUST NOT be conflated in status reporting.
6. FAILURE CONDITIONS
A rebalancing failure occurring after local finality MUST NOT retroactively affect a recipient's already-settled position — see NIL-R04.
7. SECURITY CONSIDERATIONS
Treating local finality as sufficient for recipient guarantees means a downstream rebalancing failure cannot retroactively harm the recipient — see NIL-R04 for a full treatment of failure containment.
8. REFERENCE IMPLEMENTATION
The reference implementation is the NIL-0 simulation network. No production implementation of this proposal exists; behavior described here is normative for the simulation only.