Forem: obiwale ayomide

Delivery vs Payment (DvP): How CRE Solves the Hardest Problem in Finance

obiwale ayomide — Tue, 17 Mar 2026 16:12:28 +0000

Recently, I wrote about

CRE: The Missing Coordination Layer Between Traditional Banking and Blockchain.

It's time to go deeper because coordination alone isn’t enough. The real problem has always been settlement.

The Problem: Settlement Risk

At the core of every financial transaction is a simple requirement:

When one party delivers an asset, the other must pay.

This is known as Delivery vs Payment (DvP).
Asset transfer ↔ Payment transfer

Both must happen together or not at all. If they don’t, one party takes on risk.

Why DvP Breaks in Modern Systems

DvP works well inside a single system. But today’s financial world is fragmented across:

Banks
Blockchains
Custodians
Payment networks

Now consider this:
Asset → Exists on a blockchain Payment → Exists in a bank ledger

Two completely different systems.

The real question becomes:

How do you guarantee both sides settle atomically across systems that don’t trust each other?

Before CRE: The Workarounds
The industry had previously resorted to the following before the emergence of solutions such as Chainlink Runtime Environment (CRE):

Intermediaries: Dependent on intermediaries such as clearing houses and custodians to facilitate trust between two parties
Time Delays: Time periods such as T+2 reduce risks
Manual Reconciliation: Systems reconcile transactions after the fact.

All of these introduce:

Counterparty risk
Operational complexity
Capital inefficiency

Why Blockchains Didn’t Fully Solve This

Blockchains introduced atomic settlement, but only within their own environment and it works perfectly.
Token A ↔ Token B (same chain)

But:
Token (on-chain) ↔ Cash (in a bank)

This is broken because blockchains cannot:

Access bank systems
Trigger external payments
Guarantee off-chain execution

Enter CRE: A New Settlement Primitive
Chainlink Runtime Environment (CRE) introduces:

Programmable, verifiable workflows across on-chain and off-chain systems

Instead of forcing everything onto one chain, CRE connects:

Smart contracts → Chainlink Runtime Environment → External systems (banks, APIs, other chains)

This approach enables a cross-system atomic settlement

A Real Example: Cross-System DvP in Action

Recently,
Chainlink,
JPMorgan Chase (via Kinexys), and
Ondo Finance

executed a cross-chain Delivery vs Payment transaction.

This is one of the clearest real-world examples of CRE in action.

What Was Being Traded

Asset: Tokenized U.S. Treasuries (OUSG)
Payment: Bank deposit on Kinexys

Where each part lived:

Ondo Chain → Asset layer

Kinexys → Bank payment layer

CRE → Coordination + execution layer

Step-by-Step: How the Transaction Happened

Step 1: The Intent
A participant wants to buy tokenized U.S. Treasuries (OUSG).

But:

The asset is on a blockchain
The money is in a bank

Step 2: The Risk
Without coordination:

Send money first → risk losing funds

Receive asset first → risk not getting paid

In the absence of atomic settlement, there are many hidden but critical risks that may affect the transaction. When one side of a transaction is executed before the other, a party may have fulfilled their side of the transaction but may not receive anything in return. This is referred to as principal risk. Even if both parties are willing to settle, there may be timing risks due to changes in market conditions or system and participant behavior.

Step 3: CRE Coordinates the Transaction
Instead of trusting either side, both systems are connected through Chainlink Runtime Environment (CRE)

Step 4: Conditional Logic Is Enforced
CRE defines the rules:

IF payment succeeds → release asset

IF asset transfer succeeds → finalize payment

ELSE → abort everything

The transaction reverts if any of the conditions fail. This is the beauty of atomic transactions.

Step 5: Parallel Execution
Both systems are triggered simultaneously:

On Ondo Chain:

Prepare transfer of OUSG tokens

On Kinexys:

Prepare transfer of bank deposit

Step 6: Verification and Consensus
CRE nodes:

Monitor both sides
Verify execution results
Reach consensus

Step 7: Atomic Settlement

Only when both sides are confirmed:

OUSG tokens → transferred

USD deposit → transferred

If anything fails:

Everything is rolled back

This is more than just a successful transaction, it introduces a new financial primitive:

Cross-System Atomicity
DvP is no longer limited to a single ledger.
Trust-Minimized settlement as trust would only be on protocol.
No need to trust:
- The counterparty
- The bank
- The blockchain
Real-World Asset enablement as Tokenized assets can now settle against:
- Bank deposits
- Stablecoins
- Future CBDCs

For years, blockchain technology has claimed the promise of "Faster, cheaper, trustless settlement." However, until the problem of cross-system DvP is resolved, the promise is incomplete. Now, with the introduction of CRE, the settlement is not only happening on a particular blockchain but across the entire financial system.

CRE: The Missing Coordination Layer Between Traditional Banking and Blockchain

obiwale ayomide — Thu, 05 Mar 2026 00:45:03 +0000

For years, traditional banking and blockchain have operated in parallel universes.

Traditional banking runs on structured messaging systems using ISO 20022.
Blockchain runs on smart contracts using decentralized consensus.
Both move money.
Both need trust.
But neither talks to the other.

CRE (Chainlink Runtime Environment) changes this balance of power.

CRE is not a blockchain.
It is not a bank.
It is a coordination layer — a programmable execution environment powered by decentralized oracle networks that enables secure communication between off-chain financial systems and on-chain smart contracts.

CRE doesn’t replace banking.
CRE doesn’t replace blockchain.
CRE makes it possible for the two to coordinate with each other.

The Real Problem: Coordination, Not Technology

Traditional finance is a workflow-based business.

Every single financial transaction in a bank, from a wire transfer to a securities settlement, is a process that follows a specific operational flow:

Instruction received
Compliance check
Message formatted (ISO 20022)
Routed to counterparties
Ledger updated
Audit trail created

Blockchain is an event-based system.

Smart contract executes
Token is transferred
Event is emitted

However, that event does not automatically trigger a set of compliance checks in a bank.
The event does not automatically generate an ISO 20022 message.
The event does not automatically update an institutional ledger.

In traditional systems, bridging these two systems together required:

Middleware servers
Reconciliation
Batch processing
Fragile APIs
Centralized relayers

CRE brings something new to the table: workflows.

Let's consider the example of an international wire transfer.

From the customer's perspective:
We enter the details, hit send, and the funds arrive.

Behind the scenes:

The bank authenticates the user's identity.

The transaction is checked for sanctions.

An ISO 20022 message is created.

The correspondent banks work together to settle the transaction.

The ledgers are updated.

The confirmation messages are sent back.

The audit trails are stored.

This is not a single operation.
This is a whole workflow, happening across different systems.

Let's consider replacing one of the banks in the entire workflow with a blockchain network.

Without CRE:

The blockchain can't interpret the ISO 20022 messages.

The bank can't interpret the smart contract events.

We need to implement a custom backend to translate between the two systems.

With CRE:

A banking message can trigger an on-chain event.

An on-chain event can trigger the automatic generation of an ISO 20022 message.

Compliance can be integrated into the workflow.

Reporting can happen in real-time.

The user experience remains the same.
But in the background, the blockchain has been integrated into the same workflow.

Why Major Banks Are Exploring This

Institutions like JPMorgan (through Kinexys), UBS, SWIFT collaborators, and others are not experimenting with blockchain out of curiosity.

They have strategic reasons.

Efficiency & Cost Reduction

Traditional cross-border settlements are slow and layered with intermediaries.

Blockchain offers:

Near-instant settlement
Reduced counterparty risk
Automated reconciliation

CRE enhances this by coordinating blockchain settlement with traditional reporting systems, reducing operational overhead.

Real-Time Reconciliation

Today, banking systems heavily utilize batch processing and reconciliation systems.

Blockchain technology allows for deterministic state changes with timestamps.

CRE facilitates this by ensuring:
Integration with existing ledger systems
Generation of structured financial messages
Record maintenance

This removes friction from the back-end systems.

ISO 20022 Integration

ISO 20022 is the global financial messaging standard.

It’s the language of modern banking.

But blockchains don’t natively support this language.

CRE can:

Translate ISO 20022 instructions into programmable blockchain actions.
Generate ISO 20022 compliant outputs from on-chain state changes.

That’s important.
It means banks don’t have to abandon their infrastructure to benefit from blockchain.

A More Detailed Analogy: The Bank Operations Floor

Imagine the operations floor of a large bank.

There are:

Risk teams
Compliance teams
Settlement systems
Messaging systems
Ledger systems
Audit systems

When a major transaction happens, all these units coordinate.

Now imagine a digital “conductor” that:

Receives a financial instruction
Automatically calls compliance checks
Formats standardized financial messages
Routes instructions to the right systems
Updates ledgers
Logs immutable records
Confirms completion

CRE acts like that conductor — but across both banking systems and blockchain networks.

It ensures:

On-chain actions integrate with traditional workflows.
Traditional banking messages can trigger programmable execution.
Everything remains auditable and structured.

The Deeper Shift: From Transactions to Coordinated Infrastructure

The most significant change is this:

Blockchains have been transactional.
Banking has been procedural.
CRE makes blockchains procedural.

Instead of smart contract events, you get institutional workflows.

Instead of:
“Something happened on chain, now go reconcile it manually.”

You get:
“Something happened, and the entire institutional workflow happened automatically.”

That is synergy.

The Bigger Vision

This is not about replacing SWIFT.
This is not about replacing banks.
This is not about replacing traditional finance.

This is about integration.

CRE enables:

Structured financial messaging (ISO 20022)
Blockchain programmability
Real-time settlement
Compliance-aware execution
Cross-system coordination

This is about bridging decentralized execution and institutional operational standards.

Invisible complexity.
Visible reliability.

This is why the biggest financial institutions are taking a look.
This is why the conversation around blockchain is shifting from speculation to infrastructure.

Reading Contract State at a Past Block Using Wagmi

obiwale ayomide — Thu, 08 Jan 2026 16:56:35 +0000

There was a moment when I needed to answer a deceptively simple question:

“What was the price of this asset then, not now?”
Not five minutes ago.
Not the current block.
But at a very specific point in the past.

I was working on a feature that needed historical pricing for an asset. Not off-chain charts, not an indexer snapshot, but the actual on-chain value that existed at a given time. Since the asset used Chainlink price feeds, I assumed this would be straightforward.

It wasn’t.

At first, I kept getting the current price no matter what I tried. That’s when I realized something important: most examples show you how to read contract state, but very few show you how to read contract state at a specific block.

That’s where Wagmi quietly shines.

The Core Idea

Ethereum (and EVM chains in general) allow you to query contract state as it existed at any historical block. If a contract method is view or pure, you can read it at a past block without any special indexing infrastructure.

Wagmi exposes this directly through blockNumber.

So instead of asking:
“What does the contract return now?”

You ask:
“What did the contract return at block X?”

For price feeds, this is gold.

The Scenario: Chainlink Price at a Past Time

Chainlink price feeds expose methods like:
latestRoundData()
getRoundData(roundId)

If you already know the round ID, you can query it directly. But sometimes you don’t. Sometimes all you know is the time.

A reliable approach is:

Convert the timestamp you care about into a block number
Read the price feed contract at that block
Let’s focus on step 2 using Wagmi.
Reading a Contract Method at a Specific Block
Wagmi’s readContract (or useReadContract) accepts a blockNumber parameter.

import { readContract } from '@wagmi/core'
import { parseAbi } from 'viem'

const aggregatorAbi = parseAbi([
  'function latestRoundData() view returns (uint80,int256,uint256,uint256,uint80)'
])

const priceFeedAddress = '0x...'

const blockNumber = 18_500_000n

const data = await readContract({
  address: priceFeedAddress,
  abi: aggregatorAbi,
  functionName: 'latestRoundData',
  blockNumber,
})

What happens here is subtle but powerful.

Wagmi asks the RPC node:

“Pretend the chain is at block 18,500,000. What does this function return?”

The result is exactly what the Chainlink contract would have returned at that block, not today.

Why This Works

Ethereum nodes store historical state. When you specify a blockNumber, the node executes the call against that historical snapshot.

No subgraph.
No off-chain cache.
No guesswork.

Just deterministic blockchain state.

Mapping Time to Block

You usually don’t know the block number upfront. You know a timestamp.

Typical approaches:

Binary search blocks by timestamp using eth_getBlockByNumber

Use a helper API once, then cache the mapping

Use an archive node for accuracy

Once you have the block number, Wagmi does the rest.

Frontend Example with React

If you’re using Wagmi hooks in a React app:

import { useReadContract } from 'wagmi'

const { data } = useReadContract({
  address: priceFeedAddress,
  abi: aggregatorAbi,
  functionName: 'latestRoundData',
  blockNumber: 18_500_000n,
})

This is especially useful for:

Historical charts
Auditing old positions
Liquidation simulations
“What-if” analytics
Dispute resolution in DeFi

Important Caveats

RPC support matters
You need an RPC that supports historical reads. Some free providers prune old state.

Performance
Historical reads are slightly heavier. Cache results when possible.

Final Thoughts
Wagmi doesn’t make a big deal out of this feature, but once you realize you can read contract state at any point in time, a lot of problems suddenly become simpler.