Finality: The Fourth Pillar of NEW-EIP

TL;DR

There exists a fundamental philosophical conflict between blockchain’s immediate finality and financial regulation’s legal finality. ERC-RCP presents an innovative two-phase finality mechanism that implements PFMI Principle 8‘s requirements on-chain. Through a dual structure of Provisional Finality (immediate execution) for DeFi compatibility and Absolute Finality (legal confirmation) for regulatory compliance, this represents the first attempt to meet G20 financial standards while maintaining decentralization. This is not a compromise but an evolution – recreating the true settlement finality demanded by PFMI in a decentralized manner.

---

The Finality Paradox of Two Worlds

In 2024, Vitalik Buterin proposed Single-Slot Finality for Ethereum, presenting a vision to reduce block confirmation time from 15 minutes to 12 seconds. Meanwhile, the Principles for Financial Market Infrastructures (PFMI) published by the Bank for International Settlements (BIS) and IOSCO demands “clear and certain final settlement by the end of value date” in Principle 8.

Between these two paradigms exists a seemingly unbridgeable gap. Blockchain pursues speed and efficiency but lacks legal protection, while traditional finance ensures certainty and safety but operates slowly.

Here we face a fundamental question:

“If we make the irreversible reversible, is it still final?”

PFMI and Blockchain: Two Conflicting Paradigms

📘 What is PFMI (Principles for Financial Market Infrastructures)?

Published in 2012 by BIS-CPMI and IOSCO, these 24 principles constitute the global standard for financial market infrastructure adopted by all G20 countries. Particularly, Principle 8 (Settlement Finality) requires “clear and certain final settlement by the end of value date,” meaning legally clear and certain settlement completion.

To clearly understand the differences between traditional finance, current blockchain, and the RCP principle, let’s examine the following table:

Requirement	PFMI Traditional Finance	Current Blockchain	RCP Principle
Settlement Timing	T+2 with certainty	Instant but reversible	Instant + 24hr certainty
Legal Basis	National law	Code is Law	Code with Law
Risk Management	Centralized CCP	Individual risk	Regulatory window
Dispute Resolution	Court system	None/Fork	On-chain arbitration
Finality Definition	Legal moment	Probabilistic	Two-phase deterministic

These differences reflect not merely issues of technical implementation. They reflect fundamentally different philosophies about the source of trust.

Reinterpreting Atomicity: The True Meaning of All or Nothing

In database ACID properties, Atomicity means a transaction either completely succeeds or completely fails. Blockchain atomicity ensures all operations within a single transaction succeed or fail together. However, legal atomicity is a more complex concept.

UC Berkeley Law Professor Melvin Eisenberg explains:

“The classical law approach to the certainty principle reflects the binary nature of classical contract law. Indeed, this approach is often referred to as the all-or-nothing rule.”

RCP integrates these three atomicity concepts to present a new paradigm of “Atomic across time and space”. This is a mechanism that simultaneously ensures immediate technical execution and delayed legal certainty.

ERC-RCP’s Two-Phase Finality Architecture: On-Chain Implementation of PFMI Principle 8

Architecture Overview

ERC-RCP’s innovative two-phase finality mechanism is implemented as follows:

enum FinalityState {
   PENDING,       // Submitted, not included
   PROVISIONAL,   // Executed, under review (DeFi compatible)
   INSTANT_FINAL, // Instant finality (low-risk assets)
   DELAYED_FINAL, // Delayed finality (PFMI compliant)
   ROLLED_BACK    // Regulatory intervention
}

struct TransactionFinality {
   FinalityState state;
   uint256 timestamp;
   bool requiresRegulatoryWindow;
   uint256 assetRiskLevel; // 0: Low, 1: Medium, 2: High
}

PFMI Key Considerations Mapping

Let’s examine how PFMI Principle 8’s key considerations are implemented in ERC-RCP:

• KC 8.1: “Settlement by end of value date” → 24-hour regulatory window
• KC 8.2: “Intraday finality” → Immediate execution through Provisional finality
• KC 8.3: “Clear rules for finality” → Rules codified in smart contracts

This mapping is not mere technical translation. It’s a philosophical attempt to achieve both legal certainty and technical efficiency simultaneously.

The Philosophical Justification of Conditional Finality

Schrodinger’s Transaction: A State Both Final and Not Final

Like Schrodinger’s cat in quantum mechanics, a transaction in RCP’s Provisional Finality stage exists in a state that is both final and not final. From a DeFi protocol’s perspective, it’s immediately executed and final, but from a regulatory perspective, it remains subject to review.

This is an on-chain implementation of what legal philosophy calls “Conditional Rights”. We reinterpret Lawrence Lessig’s famous proposition “Code is Law” as “Code awaiting Law”. The code executes immediately but awaits legal verification.

Inevitable Compromise or Creative Solution?

Critics might argue that this two-phase approach undermines blockchain’s principle of immutability. However, we see this not as a compromise but as evolution. Between the ideal of perfect immutability and real-world legal requirements, we have found a “good enough” equilibrium.

Cross-Chain Atomic Finality: The Future of Global Settlement

The Multi-Jurisdiction Problem

In global financial markets, multiple jurisdictions intersect. When a transaction starts in New York, passes through London, and completes in Tokyo, which country’s “value date” should apply?

ERC-RCP solves this problem as follows:

struct CrossChainFinality {
    mapping(uint256 => JurisdictionFinality) jurisdictions;
    uint256 primaryJurisdiction;
    uint256 globalFinalityTimestamp;
}

function determineFinalityJurisdiction(
    address[] memory participants,
    uint256[] memory chainIds
) internal view returns (uint256) {
    // Analyze participants' jurisdictions
    // Apply the most stringent regulatory requirements
    return mostStrictJurisdiction(participants, chainIds);
}

Overcoming the Limitations of Hashed Timelock Contracts

While existing HTLCs (Hashed Timelock Contracts) provide cross-chain atomicity, they don’t consider the possibility of regulatory intervention. ERC-RCP introduces a new concept called Regulatory Timelock:

• Technical timelock: Minimum time for cross-chain synchronization
• Regulatory timelock: Additional time for regulatory review
• Conditional release: Final confirmation only when both conditions are met

Regulatory Intervention Mechanism: The Design Philosophy of the Rollback Window

The regulatory intervention mechanism is both the most controversial and most innovative part of ERC-RCP:

modifier withinRegulatoryWindow(bytes32 txHash) {
    TransactionFinality memory tf = transactions[txHash];
    require(
        block.timestamp < tf.timestamp + REGULATORY_WINDOW,
        "PFMI: Regulatory intervention period expired"
    );
    _;
}

function regulatoryRollback(
    bytes32 txHash, 
    string memory courtOrder
) external 
    onlyRegulator 
    withinRegulatoryWindow(txHash) 
{
    // PFMI Principle 1: Clear legal basis
    transactions[txHash].state = FinalityState.ROLLED_BACK;
    transactions[txHash].legalReference = courtOrder;

    // Handle all affected subsequent transactions
    handleCascadingEffects(txHash);

    emit RegulatoryIntervention(txHash, courtOrder, block.timestamp);
}

This design embodies important philosophical choices:

1. Transparency: All regulatory interventions are recorded on-chain
2. Time limitation: Indefinite intervention is impossible
3. Legal basis: All interventions require legal grounds (courtOrder)
4. Cascading effect management: Automatically handles the impact of rollbacks

Failure and Recovery: Risk Management of PFMI Principle 3

Processing Chain Transactions During the Provisional Period

When transactions performed in Provisional Finality state chain together, what happens if one transaction is rolled back? ERC-RCP manages this by building a Dependency Graph:

struct DependencyGraph {
    mapping(bytes32 => bytes32[]) dependencies;
    mapping(bytes32 => uint256) depth;
}

function calculateRollbackImpact(bytes32 txHash) 
    public view 
    returns (bytes32[] memory affectedTxs, uint256 totalValue) 
{
    // Recursively identify all affected transactions
    // Evaluate each transaction's state and value
    // Calculate rollback possibility and cost
}

The “Too Big To Rollback” Problem

Some transactions generate so many subsequent transactions that rollback would create systemic risk. This is similar to the “Too Big To Fail” banks problem during financial crises.

RCP’s principles:

• Threshold setting: Transactions above certain size require additional verification
• Graduated finality: Different finality timelines based on importance
• Insurance mechanism: Compensation fund for non-rollbackable cases

The Regulatory Trilemma: Overcoming the Impossible Triangle

Like blockchain’s trilemma (scalability, security, decentralization), regulatory compliant tokenization has its own trilemma:

The Regulatory Trilemma

• Immediate Settlement: Instant transaction processing
• Legal Certainty: Legal certainty and protection
• Decentralization: Decentralized governance

Traditionally, achieving all three simultaneously has been considered impossible.

RCP presents a “good enough” equilibrium for this trilemma:

• Immediate Settlement: Immediate execution through Provisional Finality
• Legal Certainty: Complete legal certainty after 24-hour window
• Decentralization: Regulatory intervention allowed only transparently and limitedly

This is not a perfect solution, but a practical and implementable one.

Future Outlook: Toward PFMI 2.0

Limitations of Current PFMI

PFMI published in 2012 was written assuming centralized FMI (Financial Market Infrastructure). It assumes the existence of centralized institutions like Central Counterparties (CCPs) and Central Securities Depositories (CSDs).

However, with the emergence of decentralized finance, these assumptions are no longer valid. We need a new category called “Decentralized FMI”.

The Next-Generation Financial Infrastructure Standard Presented by ERC-RCP

ERC-RCP’s two-phase finality model presents a blueprint for future financial infrastructure:

1. Hybrid governance: Coexistence of decentralized operation and regulatory oversight
2. Programmable regulation: Regulatory rules codified in smart contracts
3. Transparent intervention: On-chain recording of all regulatory actions
4. Global interoperability: Seamless asset movement across jurisdictions

PFMI 2.0 will need to reflect these principles. RCP is the starting point.

Philosophical Reflection: The Essence of Finality

What is finality? Is it simply a technically irreversible state, or a legally protected state?

Aristotle distinguished between “substance” and “accident”. From RCP’s perspective:

• Substance: The economic fact of value transfer
• Accident: The technical/legal form of when it becomes final

Two-phase finality, by separating these two concepts, chooses to realize the substance immediately while confirming the form gradually.

---

Conclusion: From Code is Law to Code with Law

ERC-RCP’s two-phase finality mechanism is not merely a technical solution. It’s a philosophical attempt to harmonize two conflicting worldviews.

Lawrence Lessig’s “Code is Law” presented a cyber-libertarian vision where code itself is law. However, the moment we deal with real-world assets, we must acknowledge that interaction with existing legal systems is inevitable.

RCP presents a new paradigm called “Code with Law”. Code and law don’t oppose each other but collaborate. The fusion of technical finality and legal finality creates a new trust system.

PFMI compliance is not a constraint on DeFi. Rather, it’s a signal that DeFi is evolving into mature financial infrastructure. The future of “Regulated DeFi” that Oraclizer envisions is a world where innovation and stability coexist.

Finally, we ask again:

“Can we maintain decentralization while perfectly complying with PFMI?”

“Is the 24-hour window suitable for all jurisdictions?”

“What happens if bankruptcy occurs during Provisional finality?”

The answers to these questions are not yet complete. But RCP’s two-phase finality is an important milestone in the journey to find those answers.

---

References

[1]. BIS-CPMI & IOSCO. (2012). Principles for Financial Market Infrastructures. https://www.bis.org/cpmi/publ/d101a.pdf

[2]. Buterin, V. (2024). Possible futures of the Ethereum protocol, part 1: The Merge. https://vitalik.eth.limo/general/2024/10/14/futures1.html

[3]. Buterin, V. (2024). Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times. https://vitalik.eth.limo/general/2024/06/30/epochslot.html

[4]. Liao, N. (2020). On Settlement Finality and Distributed Ledger Technology. Yale Journal on Regulation. https://www.yalejreg.com/nc/on-settlement-finality-and-distributed-ledger-technology-by-nancy-liao/

[5]. Financial Stability Board. (2012). Principles for Financial Market Infrastructures. https://www.fsb.org/2012/04/cos_120418/