Skip links

Why Oraclizer Chose DAML/CANTON: The Only Path to $6 Trillion in Institutional Liquidity

TL;DR

Canton Network is not just one of the many DLTs—it’s a live operational network hosting $6 trillion in tokenized real-world assets as of late 2025, managed by actual financial institutions. The reason DAML/CANTON was chosen by major financial institutions like Goldman Sachs, BNP Paribas, and HSBC is clear: it solves privacy, legal finality, and complex permission management that existing blockchains cannot address. Oraclizer is designed to serve as the bidirectional bridge connecting this massive financial liquidity with DeFi, transcending the role of a mere technology provider to become a strategic value creator. Through OracleMint and the CANTON Driver, Oraclizer is designed to enable complete state synchronization between traditional finance infrastructure and the blockchain world, making this technological foundation not just a choice but an inevitable necessity.

The current RWA tokenization market is paradoxical. Everyone talks about the future of tokenization, but in reality, most tokenized assets exist as isolated islands. Why? The problem is not blockchain technology itself, but the fundamental limitation that blockchains cannot accommodate the structural requirements of financial infrastructure.

The reality we face is this: financial institutions want blockchain innovation, but cannot abandon the regulatory frameworks, privacy requirements, and legal enforceability of existing systems. This is precisely why most RWA projects fail. They tried to fit finance into blockchain, rather than fitting blockchain into finance.

This article provides an in-depth analysis of how DAML/CANTON reversed this paradigm, and what strategic opportunities Oraclizer has captured within this ecosystem through its technology stack choices.

The Hidden Complexity of Financial Infrastructure

The Inevitable Reasons for Legacy Systems

The T+2 settlement cycle in financial systems is not merely a technical constraint. While the U.S. transitioned to T+1 on May 28, 2024, the practical difficulties of requiring affirmation, allocation, and trade confirmation to occur effectively at T+0 became apparent. This is not a technology problem but an operational complexity issue.

More importantly, there’s the regulatory reporting framework. MiFID II requires investment firms to determine the best outcome using total consideration, including the price of the financial instrument and execution costs, when executing orders on behalf of retail clients. This means not just recording transactions, but proving regulatory compliance at every stage of the transaction.

The coordination mechanisms among financial institutions are also complex. Central Securities Depositories (CSDs), Custodians, and Clearing Houses each have unique roles and responsibilities, and their interactions follow protocols established over decades.

Structural Limitations of EVM Smart Contracts

The transparency of public blockchains is a fatal weakness for financial institutions. When all transactions are public, the following problems arise:

Strategy Exposure Risk: If information that Goldman Sachs is purchasing large amounts of specific bonds is exposed to competitors in real-time, this becomes an opportunity for market manipulation. In financial markets, information asymmetry is a legitimate competitive advantage, and protecting it is essential.

Simple Permission Models: Simple access controls like Solidity’s onlyOwner cannot express the complex permission structures of financial contracts. For example, in syndicated loans, various parties such as the lead arranger, participating banks, borrower, and guarantor have different permissions and obligations.

Absence of Legal Finality: Just because a smart contract executes in code doesn’t automatically grant it legal enforceability. Financial contracts operate within complex legal contexts including jurisdiction, governing law, and dispute resolution procedures.

Financial System Requirements vs Current Blockchain Capabilities

Privacy & Compliance
Transaction Confidentiality
TradFi
Blockchain
MiFID II requires selective disclosure
Regulatory Reporting
TradFi
Blockchain
Automated but lacks privacy controls
Access Control
Role Granularity
TradFi
Blockchain
Complex multi-party roles required
Legal Authority
TradFi
Blockchain
Court orders & regulatory intervention
Settlement & Finality
Legal Finality
TradFi
Blockchain
Technical vs legal finality gap
Settlement Flexibility
TradFi
Blockchain
T+0 to T+2 flexibility needed
Traditional Finance Capability
Current Blockchain Capability

Financial Requirements vs Blockchain

Privacy & Compliance
Traditional Finance
Complete
Current Blockchain
Limited
Lacks selective disclosure & privacy controls
Access Control
Traditional Finance
Complete
Current Blockchain
Basic
Lacks complex role granularity & legal authority
Settlement & Finality
Traditional Finance
Complete
Current Blockchain
Partial
Technical vs legal finality gap exists
Traditional Finance
Current Blockchain
Figure 1: Financial System Requirements vs Blockchain Limitations

“Financial institutions don’t adopt blockchain not because they’re conservative, but because existing blockchains don’t meet the structural requirements of finance.”

DAML/CANTON: Implementation of Technical Inevitability

Mathematical Completeness and Formal Verification

DAML(Digital Asset Modeling Language) is designed based on Haskell to ensure the mathematical precision essential for financial contracts. DAML supports formal verification that works almost instantly without user interaction through static analysis tools, while being sufficiently expressive for important common use cases.

Benefits of Pure Functional Programming:

  • Elimination of Side Effects: Prevents unpredictable state changes at the source
  • Compile-Time Verification Through Type System: Minimizes runtime error possibilities
  • Mathematical Provability: DAML’s strong typing means that the behavior of functions can be automatically checked by the DAML system, helping programmers reason about how each part of a program affects ledger state

This is fundamentally different from Solidity. In Solidity, vulnerabilities like reentrancy attacks, integer overflows, and unexpected gas exhaustion are often discovered only after deployment. DAML blocks these issues at the compilation stage.

Need-to-Know Privacy Model

DAML’s innovative privacy model perfectly meets the core requirements of financial institutions. DAML is a language of privacy, where only data that parties have access rights to is disclosed. Since parties and contracts are native constructs of the language, the right of specific parties to view details of specific contracts is a fundamental concept that can be directly inferred.

What this means in actual financial transactions:

Selective Information Disclosure: In bond issuance, the issuer and lead manager can see all information, but individual investors can only see their allocation. Regulatory agencies can supervise the entire transaction as observers when necessary.

Competitive Advantage Protection: Goldman Sachs Digital Asset Platform (GS DAP®) operates natively on Canton, providing tokenization services for regulated financial markets. Each institution can perfectly protect its trading strategies and positions from competitors. This privacy-preserving architecture is what Oraclizer inherits and extends through its CANTON Driver implementation.

DAML Privacy Model vs Public Blockchain
Public Blockchain DAML Need-to-Know Model Bond Transaction $100M Treasury Bond Goldman → JPMorgan Goldman 👁️ Sees All JPMorgan 👁️ Sees All Competitor 👁️ Sees All Public 👁️ Sees All ⚠️ Strategic Information Exposed to All Bond Contract $100M Treasury Bond Goldman → JPMorgan Goldman ✓ Signatory JPMorgan ✓ Signatory Regulator 👁️ Observer Competitor No Access ✓ Privacy Preserved, Compliance Enabled
🔓 Public Blockchain Model
Goldman Sachs (Party)
👁️ Sees entire $100M bond transaction
JPMorgan (Counterparty)
👁️ Sees entire transaction details
Competitors
👁️ Can track Goldman’s trading strategy
Public/Anyone
👁️ Full visibility of all transactions
⚠️ Strategic information exposed to all participants
🔒 DAML Need-to-Know Model
Goldman Sachs (Signatory)
✓ Full access to contract
JPMorgan (Signatory)
✓ Full access to contract
Regulator (Observer)
👁️ Read-only access for compliance
Competitors
❌ No access – strategy protected
✓ Privacy preserved while enabling compliance
Legend
Full Access
Read Only
No Access
Figure 2: DAML Privacy Model vs Public Blockchain

Implementation of Powerful Permission Models

DAML’s permission model accurately reflects the complex structure of financial contracts:

Signatory: Parties who can create and modify contracts. For example, in a loan contract, both the lender and borrower must be signatories.

Observer: Parties who can view but not modify contracts. Regulatory agencies, auditors, and credit rating agencies fulfill this role.

Controller: Parties who can execute specific choices. For example, the borrower can execute early repayment, but the lender cannot.

Through this granular permission model, complex financial products like syndicated loans, structured products, and derivatives can be accurately modeled. Oraclizer’s OracleMint leverages this permission model to ensure that tokenized assets maintain their regulatory compliance structure when synchronized to on-chain environments.

Real Implementation Case: Complexity of Syndicated Loans

Beyond abstract explanations, let’s examine concretely how DAML implements actual complex financial transactions. Syndicated loans, where multiple lenders provide funds to a single borrower, have one of the most complex permission structures in financial contracts.

Party Structure of Syndicated Loans

A typical $1 billion syndicated loan involves the following parties:

  • Lead Arranger: Goldman Sachs
  • Participating Banks: JPMorgan ($300M), BNP Paribas ($200M), HSBC ($200M), 5 other banks ($60M each)
  • Borrower: Fortune 500 company
  • Guarantor: Borrower’s parent company
  • Regulatory Observer: Relevant financial supervisory authority

Each party has different permissions and obligations, which must be accurately expressed in code.

DAML Implementation Sophistication

template SyndicatedLoan
  with
    leadArranger : Party
    participatingBanks : [(Party, Decimal)]  -- (bank, loan share)
    borrower : Party
    guarantor : Party
    regulator : Party
    principal : Decimal
    interestRate : Decimal
    maturityDate : Time
  where
    signatory leadArranger, borrower
    observer regulator, guarantor
    
    -- Only Lead Arranger can propose loan term amendments
    choice ProposeAmendment : ContractId AmendmentProposal
      with
        newTerms : LoanTerms
      controller leadArranger
      do
        create AmendmentProposal with
          loan = this
          proposedTerms = newTerms
          approvals = []
    
    -- Participating banks can only view their own share
    nonconsuming choice ViewMyShare : Decimal
      with
        bank : Party
      controller bank
      do
        return $ fromSome $ lookup bank participatingBanks
    
    -- Only borrower can execute early repayment
    choice PrepayLoan : ContractId PrepaymentReceipt
      with
        amount : Decimal
      controller borrower
      do
        -- Distribute to each bank proportionally by share
        forA participatingBanks $ \(bank, share) ->
          create PaymentToBank with
            bank = bank
            amount = amount * share / principal
        create PrepaymentReceipt with loan = this, amount
    
    -- Regulator can view entire loan structure (without privacy breach)
    nonconsuming choice RegulatoryInspection : LoanStructure
      controller regulator
      do
        return LoanStructure with
          totalPrincipal = principal
          numberOfBanks = length participatingBanks
          exposureDistribution = participatingBanks

Why This Is Impossible in Solidity

Attempting to implement the same structure in Solidity encounters the following fundamental limitations:

1. Absence of Privacy

// Solidity: All information is public
mapping(address => uint256) public lenderShares;  // Anyone can see!

// Information that JPMorgan lent $300M is exposed to competitors
// This becomes an opportunity for market manipulation

In DAML, each bank can see only their own share through ViewMyShare, and cannot know other banks’ positions. Only the Lead Arranger and regulator see the full structure.

2. Poverty of Permission Models

// Solidity: Simple modifier
modifier onlyLeadArranger() {
    require(msg.sender == leadArranger);
    _;
}

// Problem: Cannot express granular permissions like "can view but not execute"
// The observer concept itself doesn't exist

DAML’s observer keyword natively supports the permission to “view but not modify contracts.” This is a fundamentally different concept from Solidity’s view functions.

3. Lack of Legal Finality

// Solidity: Simple data structure
struct Loan {
    uint256 principal;
    uint256 interestRate;
    uint256 maturityDate;
}

// Problem: No legal record of "who created this contract?" "who signed?"

DAML’s signatory keyword means legal signature. This is not just the address that sent the transaction, but records the parties who legally consented to contract creation.

DAML Implementation Haskell-based
template SyndicatedLoan with — Native party types with roles leadArranger : Party participatingBanks : [(Party, Decimal)] borrower : Party regulator : Party where — Legal signatures required signatory leadArranger, borrower — View-only permission observer regulator — Each bank sees ONLY their share choice ViewMyShare : Decimal controller bank do lookup bank participatingBanks
Solidity Limitations EVM-based
contract SyndicatedLoan { // ALL data is public! mapping(address => uint256) public lenderShares; address public leadArranger; address public borrower; // Simple binary permission modifier onlyLeadArranger() { require(msg.sender == leadArranger); _; } // Cannot hide individual shares! // No concept of “observer” // No legal enforceability }
Selective Visibility
Each party sees only what they need to see. JPMorgan cannot see Goldman’s position.
Legal Finality
‘signatory’ means legal signature, not just msg.sender. Enforceable in court.
Granular Permissions
Signatory, Observer, Controller – each with specific rights, not just owner/non-owner.
Figure 3: DAML Permission Model Deep Dive – Syndicated Loan Architecture

Practical Implications

As of 2024, the global syndicated loan market is approximately $5 trillion annually. A significant portion of this hasn’t been digitized because existing blockchains couldn’t handle the complexity described above.

CANTON is the only technology that can bring this $5 trillion market on-chain. Goldman Sachs building GS DAP with DAML was not coincidental. And Oraclizer’s strategic decision to build OracleMint on DAML/CANTON means we can serve this massive market with native regulatory compliance from day one.

Cross-Domain Interoperability

The core value of Canton Network is atomic transactions across domains. Canton Network is the only public permissionless layer 1 blockchain that delivers composable privacy and institutional-grade regulatory compliance at scale.

Practical implications:

  • JP Morgan’s Onyx and Goldman Sachs’s GS DAP can interact directly
  • Execute atomic settlements while maintaining each institution’s privacy
  • Realize P2P transactions without central intermediaries

Oraclizer extends this cross-domain capability to the broader blockchain ecosystem through the CANTON Driver, enabling atomic state synchronization between traditional finance and DeFi.

Canton Network: The Hidden Financial Turtle Ship

The Scale of a Quiet Revolution

Canton Network has quietly built a massive ecosystem. As of late 2025, Canton Network hosts $6 trillion in tokenized real-world assets (RWA), including bonds, money market funds, alternative investments, commodities, repo agreements, mortgages, and even life insurance products.

Particularly noteworthy is Broadridge’s Distributed Ledger Repo (DLR), which processes approximately $280 billion in tokenized U.S. Treasury repo transaction volume daily, totaling about $4 trillion monthly. This means Wall Street’s overnight funding machine is operating on-chain—not as an experiment, but as actual infrastructure.

Substantial Commitment of Participating Institutions

In June 2025, Digital Asset completed a $135 million strategic funding round led by DRW Venture Capital and Tradeweb Markets, with participation from Goldman Sachs, Citadel Securities, BNP Paribas, DTCC, and others.

This is not just investment. Goldman Sachs’s Global Head of Digital Assets, Mathew McDermott, stated: “Our longstanding relationship with Digital Asset stems from deep conviction in the strength of their technology, which continues to be the foundation for the development and ongoing success of GS DAP”.

Basel III Compliance and Institutional Acceptance

The most important breakthrough is regulatory compliance. Canton’s architecture is built to meet Basel III capital standards, allowing banks to treat tokenized assets as Group 1 compliant products (same category as traditional securities).

This is revolutionary:

  • Tokenized assets receive the same regulatory treatment as traditional securities
  • No disadvantage in capital requirement calculations
  • Full participation of institutional investors possible

Oraclizer’s Strategic Positioning

CANTON Driver: Proof of Technical Elegance

The integration between Oraclizer and Canton is remarkably elegant:

template OracleContract
  with
    asset : Asset
    owner : Party
    oraclizer : Party
  where
    signatory owner
    observer oraclizer
    
    choice SyncToOnChain : ContractId OnChainState
      controller owner
      do
        create OnChainState with
          assetId = asset.id
          owner = owner
          -- Oraclizer synchronizes this state on-chain

What this simple code demonstrates:

  • Direct integration through Canton’s gRPC API
  • No need for complex intermediary layers
  • DAML contracts already include regulatory compliance logic
  • Oraclizer performs only the “on-chain representation” role

This architectural simplicity is possible because Oraclizer’s Oracle Interoperability Protocol (OIP) was designed from the ground up to be compatible with DAML’s permission and privacy model.

Why Other RWA Projects Failed

To better understand Canton’s success, we need to analyze why other approaches hit walls.

Ondo Finance: The Privacy Wall

Ondo launched the OUSG token, tokenizing U.S. Treasuries on EVM. As of January 2025, it recorded approximately $600 million in TVL, but this is 0.01% compared to Canton’s $6 trillion.

Fundamental limitation:

// Ondo's OUSG contract (simplified)
contract OUSG is ERC20 {
    mapping(address => uint256) public balances;  // All balances are public!
    
    function transfer(address to, uint256 amount) public {
        // Problem: All transaction history is public
        // JPMorgan buys $100M → immediately exposed to competitors
    }
}

Why institutional investors don’t participate:

  • Information that Goldman Sachs has a large position in specific Treasuries is the trading strategy itself
  • If this information is disclosed in real-time, it becomes a target for market manipulation
  • Result: Large institutions avoid Ondo

Centrifuge: Poverty of Permission Models

Centrifuge implemented real asset-backed lending on Polkadot. However, it has limitations in expressing complex financial contracts.

Syndicated loan scenario:

// Centrifuge's simplified structure
pub struct Loan {
    pub borrower: AccountId,
    pub lender: AccountId,  // Only one lender possible
    pub amount: Balance,
}
// Problem: Syndicated loans with multiple lenders impossible
// Cannot express differentiated permissions of Lead Arranger, Participating Banks

DAML’s [(Party, Decimal)] structure natively supports arbitrary numbers of participants and their respective permissions. Centrifuge would need separate complex logic to implement this.

Maker/Compound: Lack of Legal Finality

DeFi protocols implement collateralized lending, but this is merely code execution without legal enforceability.

Real case:

In 2020, a user who borrowed USDC using DAI as collateral on Compound filed a lawsuit after being liquidated, claiming it was due to a “smart contract bug”. The problem was that even the contract parties were unclear.

DAML’s solution:

template LegallyBindingLoan
  with
    lender : Party  -- Lender as legal entity
    borrower : Party  -- Borrower as legal entity
    jurisdiction : Text  -- "New York Law"
    disputeResolution : Text  -- "AAA Arbitration"
  where
    signatory lender, borrower  -- Legal signature
    
    -- This contract becomes enforceable evidence in court

DAML’s signatory is not just msg.sender, but signifies parties assuming legal responsibility. This is perfectly compatible with traditional finance’s legal framework.

Comparison Summary: Why Only Canton Succeeded

In conclusion, other projects failed not due to lack of technical capability, but because of wrong philosophical starting points. They tried to “fit finance into blockchain,” while Canton “fit DLT into finance.” And Oraclizer’s choice of DAML/CANTON as the foundation for OracleMint means we inherit this correct philosophical approach—making regulatory compliance and institutional trust not afterthoughts, but core design principles.

Solving the Liquidity Gap

Current RWA projects’ failure pattern:

Token Issuance → Liquidity Shortage → DeFi Integration Failure → Limited Practical Value

Oraclizer’s differentiated approach:

Canton Ecosystem → Access to Existing Liquidity Pools → DeFi Connection via Oraclizer → Bidirectional Value Flow

Immediately Accessible Liquidity: Instant access to Canton Network’s $6 trillion in assets. These are not hypothetical numbers but real assets operated by actual financial institutions.

Bidirectional Value Creation:

  • TradFi → DeFi: Use Canton assets as collateral in Aave, Compound
  • DeFi → TradFi: Provide DeFi yield to Canton institutional investors

Through OracleMint’s DAML implementation and the CANTON Driver, Oraclizer doesn’t just bridge these worlds—it creates a complete state synchronization layer that maintains regulatory compliance throughout the entire value flow.

Realization of Complete State Synchronization

Oraclizer’s OIP (Oracle Interoperability Protocol) is perfectly compatible with DAML/CANTON:

OCID System: Maps DAML Party IDs to on-chain addresses, providing traceability while preserving privacy.

Bidirectional Synchronization:

  • DAML contract state → On-chain RWA Registry
  • On-chain transactions → DAML contract updates

Regulatory Compliance Automation: OIP’s five regulatory principles (Completeness, Traceability, Confidentiality, Enforceability, Tokenizability) naturally combine with DAML’s native features. This is not coincidental—OIP was architecturally designed to complement DAML’s permission model, making Oraclizer the natural bridge between Canton and the broader blockchain ecosystem.

Oraclizer-Canton Integration Architecture
Canton Network (Off-chain Financial Infrastructure) Oraclizer L3 (State Synchronization Engine) Public Blockchains (DeFi Ecosystem) Goldman Sachs GS DAP® $2T+ Assets Canton BNP Paribas Neobonds Canton HSBC Orion Platform Canton Broadridge DLR Repo $280B/day Canton 60+ Institutions Citadel, Tradeweb, Circle, DTCC… $6T Total Oracle State Synchronizer Complete State Sync Engine • OCID Identity Mapping • Bidirectional Sync • RCP Compliance L3 Infrastructure • Polygon CDK • zkVerify Integration • Base L2 Settlement RWA Registry • Asset State Management • Regulatory Actions • Cross-chain Bridge Base L2 Primary Settlement EVM Arbitrum DeFi Hub EVM Optimism DeFi Integration EVM DeFi Protocols • Aave • Compound • Uniswap Other Chains Ethereum, BSC, Polygon, etc. State Updates Regulatory Events RWA Tokens DeFi Liquidity Key Value • $6T Assets • 24/7 Trading • Full Compliance
Canton Network Layer C
$6T
Total Assets
60+
Banks
$280B
Daily
Goldman Sachs
GS DAP®
$2T+
BNP Paribas
Neobonds
EU
HSBC
Orion
ASIA
Broadridge
DLR Repo
$280B/d
State Sync
Off-chain ↔ On-chain
Oraclizer L3 Engine O
SS State Sync
  • Bidirectional sync
  • OCID mapping
  • RCP compliance
  • Real-time sync
L3 Infrastructure
  • Polygon CDK L3
  • zkVerify integration
  • 93% cost reduction
  • Validium mode
RG Registry
  • Asset management
  • Regulatory actions
  • Bridge contracts
  • Single source
RC Compliance
  • 6 regulatory actions
  • Real-time monitoring
  • Global standards
  • Auto enforcement
Asset Flow
Cross-chain DeFi
DeFi Ecosystem D
CH Chains
Base L2
Primary
Arbitrum
DeFi Hub
Optimism
Integration
Ethereum
Mainnet
DF Protocols
Aave Lending
Compound Borrow
Uniswap Trading
100+ More Various
Integration Results
Canton→DeFi
DeFi→Banks
24/7 Trade
Figure 4: Oraclizer-Canton Integration Architecture

Realization of RWA 2.0: Innovation Embracing Legacy

Paradigm Shift

If RWA 1.0 was about exploring the possibility of “representing real-world assets on blockchain,” RWA 2.0 is a mature integration paradigm that fully embraces each industry’s legal frameworks and legacy systems while realizing blockchain innovation.

Oraclizer plays a central role in this paradigm:

  • Extending the financial infrastructure built by DAML/CANTON to the blockchain world
  • Providing the balance point between privacy and transparency
  • Realizing the coexistence of regulatory compliance and decentralization

Capturing Strategic Opportunities

In August 2025, Bank of America, Circle, Citadel Securities, and Tradeweb executed the first on-chain weekend funding transaction, exchanging tokenized Treasuries for USDC. This signals the beginning of 24/7 settlement.

Oraclizer stands at the center of this innovation:

  • Connecting Canton’s institutional liquidity with DeFi’s innovative protocols
  • Implementing a financial system that operates on weekends and holidays
  • Providing complete interoperability through cross-chain state synchronization

Finance in 2026: Concrete Realization Scenarios

Beyond philosophical vision, let’s examine what changes the combination of Oraclizer and Canton will actually bring through concrete scenarios.

Scenario 1: Saturday Afternoon International Settlement (2026 Q2)

Current (2025):

  • Transfer initiated after 5 PM Friday → Completed Monday morning (T+3 days)
  • Exposure to weekend exchange rate volatility risk
  • Emergency funding impossible

Canton + Oraclizer (2026):

Saturday 14:00 (Seoul) 
  ↓ Samsung Finance provides Treasury collateral to GS DAP (Canton)
Saturday 14:05 
  ↓ Oraclizer synchronizes collateral state to Aave
Saturday 14:10 
  ↓ Execute USDC loan on Aave
Saturday 14:15 
  ↓ USDC → EUR swap (Uniswap)
Saturday 14:20 
  ↓ EUR immediately transferred to German supplier

Total time: 20 minutes
Exchange rate risk: Zero

Economic value:

  • International remittance market size: Annual $750 billion
  • Weekend/holiday emergency remittance demand: Approximately 10% ($75 billion)
  • If Oraclizer captures just 5% of this market: Annual transaction volume of $3.75 billion

Scenario 2: Real-Time Collateral Revaluation System (2026 Q3)

Current problem:

  • Collateral values updated only daily
  • Market volatility causes liquidation delays resulting in losses
  • 2023 SVB incident: Treasury collateral value plummeted → Immediate liquidation impossible → Bank failure

Canton + Oraclizer solution:

template DynamicCollateral
  with
    borrower : Party
    lender : Party
    collateral : Asset  -- Canton's tokenized Treasury
    loanAmount : Decimal
    oraclizer : Party
  where
    signatory borrower, lender
    observer oraclizer
    
    -- Oraclizer synchronizes real-time prices
    choice UpdateCollateralValue : ContractId DynamicCollateral
      with
        newValue : Decimal  -- Chainlink + Oraclizer integrated price
      controller oraclizer
      do
        if newValue < loanAmount * 1.1  -- LTV below 110%
          then do
            -- Trigger automatic liquidation (Canton → Aave)
            create LiquidationOrder with ...
          else do
            create this with collateralValue = newValue

Practical effects:

  • Collateral value updates: Once dailyMinute-level real-time
  • Losses from liquidation delays: Estimated annual $5 billion90% reduction
  • Systemic risk mitigation: Basel III capital requirements potentially reduced by 15%

Scenario 3: Cross-Border Syndicated Loan Automation (2026 Q4)

Current process (average 90 days):

Day 1-30: Lead Arranger selection and term negotiation
Day 31-60: Recruit participating banks (manual process)
Day 61-75: Legal review and contract drafting (each country's law)
Day 76-90: Signature collection and fund transfer

Canton + Oraclizer process (average 7 days):

Day 1-2: Set conditions with smart template (DAML)
  ↓
Day 3-5: AI-based bank matching and automatic invitations
  ↓ Immediate review in each bank's Canton domain
Day 6: Cross-domain atomic signatures (Canton)
  ↓ Automatic compliance with New York law, UK law, Singapore law
Day 7: Oraclizer procures funds on-chain
  ↓ Immediate liquidity from Compound, Aave, etc.

Market impact:

  • Global syndicated loan market: Annual $5 trillion
  • Transaction time 92% reduction (90 days → 7 days)
  • Intermediary costs 60% reduction (legal fees, commissions, etc.)
  • Annual savings: Approximately $30 billion

Scenario 4: Regulatory Reporting Automation (2026 year-end)

Current regulatory reporting problems:

  • MiFID II reporting: Manual input of 65 data fields per transaction
  • Annual cost: $300 million for major banks
  • Error rate: Average 12%

Canton + Oraclizer automation:

template RegulatoryCompliantTrade
  with
    trade : TradeDetails
    regulator : Party  -- Financial supervisory authority
  where
    signatory trader, counterparty
    observer regulator
    
    -- All fields automatically populated in Canton
    ensure
      validateMiFIDII trade &&  -- Automatic validation of 65 fields
      validateBaselIII trade &&
      validateFATF trade
    
    -- Oraclizer automatically cross-references with on-chain records
    nonconsuming choice GenerateReport : RegulatoryReport
      controller regulator
      do
        onChainData <- fetchFromOraclizer trade.id
        return RegulatoryReport with
          fields = auto_populate_65_fields trade onChainData
          verified = True
          timestamp = getCurrentTime

Effects:

  • Report creation time: Weekly basisReal-time
  • Error rate: 12%Below 0.1%
  • Annual cost savings: $240 million per bank (80% reduction)
  • Applied to 50 major global banks: $12 billion savings

Timeline Summary

Strategic Implications

What these scenarios demonstrate:

  1. Immediacy: Combining blockchain’s 24/7 nature with traditional finance’s trustworthiness
  2. Automation: Removing over 90% of manual processes
  3. Cost Efficiency: Direct savings on the scale of tens of billions of dollars annually
  4. System Stability: Preventing financial crises through real-time risk management

This is not mere technical improvement but structural reorganization of financial infrastructure. Oraclizer positions itself at the center of this reorganization as essential infrastructure connecting Canton and DeFi.


Conclusion: From Inevitable Choice to Strategic Alliance

The choice of DAML/CANTON is not a simple technology stack decision. It is a philosophical stance that understands and embraces the essence of finance.

Canton Network’s $6 trillion in tokenized assets and daily $280 billion in repo transaction volume prove the success of this approach. This is not an experiment but the digital transformation of actual financial infrastructure.

Oraclizer performs the role of the only bidirectional bridge in this massive ecosystem. By connecting Canton’s institutional trust and regulatory compliance with DeFi’s innovation, opening the true RWA 2.0 era.

“Oraclizer is the final puzzle piece extending the financial infrastructure built by CANTON to the blockchain world.”

The future is clear. Only those who embrace and develop legacy, rather than reject it, can achieve true innovation. The combination of DAML/CANTON and Oraclizer is the realization of this philosophy.


Learn More

In the next article, we will explore more deeply how this technological choice leads to the new paradigm of RWA 2.0, and why embracing legacy is true innovation.

Explore Canton Network Ecosystem: Canton Network
Related Research: The Uncomfortable Truth About Current RWA Tokenization


References

[1]. U.S. Securities and Exchange Commission (SEC). (2023). SEC Finalizes Rules to Reduce Risks in Clearance and Settlement (Implementation of T+1). https://www.sec.gov/news/press-release/2023-29

[2]. ESMA. (2014). Article 27: Obligation to execute orders on terms most favourable to the client (MiFID II). https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mifid-ii/article-27-obligation-execute-orders

[3]. Digital Asset. (2024). The Canton Network Whitepaper: The Privacy-Enabled Global Ledger. https://www.canton.network/whitepapers

[4]. Digital Asset. (2023). Goldman Sachs’ Tokenization Platform GS DAP™, Leveraging Daml, Goes Live https://blog.digitalasset.com/press-release/goldman-sachs-tokenization-platform-gs-dap-leveraging-daml-goes-live

[5]. Broadridge. (2024). DLR Transacts $1 Trillion a Month. https://www.broadridge.com/article/capital-markets/dlr-transacts-1-trillion-a-month

Read Next

Insurance and Recovery Economics: Preparing for Black Swan Events
Earlier designs cut node risk by 73%, but the unpredictable 27% needs different rules. This study fixes how a staking insurance pool is sized (15% of stake, not protected value), bootstrapped, and banded; why a reserve held in its own token collapses with it; and how session protection follows the sync-degree hierarchy when security breaks mid-session.
Oraclizer Core ⋅ May 29, 2026
Tokenized Securities Under the CLARITY Act: The Weight of Codification
The CLARITY Act tokenized securities clause settles a single proposition in statute: tokenization is a delivery method, not a new asset class. That one sentence codifies the regulatory status of tokenized securities in U.S. law for the first time and derives an entire infrastructure specification for boundaries the token crosses.
Oraclizer Core ⋅ May 23, 2026
Sync Degree Hierarchy: Classifying What Assets Demand from State Synchronization
Sync degree hierarchy turns sync requirement strength into a four-level classification axis for RWA assets. S₀ static through S₃ atomic state binding form a reduction relation where causal consistency separates S₁ from S₂. Existing oracles, structurally two independent channels, are capped at S₁ by definition. Regulatory action forces S₃.
Oraclizer Core ⋅ May 20, 2026
Why RWA Isn’t Real DeFi Collateral Yet: The Non-Atomicity of the Collateral Layer
Tokenized RWA-backed stablecoin supply reached $8.5B, yet only 12% operates inside DeFi. Aave Horizon's dual structure separates rather than solves regulatory state synchronization. Three conditions from cross-border securities trading transfer into the DeFi collateral layer, with a fourth condition added when the protocol becomes a regulatory subject.
Oraclizer Core ⋅ May 14, 2026