Exploring Blockchain's 'Verschiebebahnhof' (shunting yard): The Nature of Smart Contracts and Data Oracles (Part 3)
Ethereum’s smart contracts and data oracles suffer from a fundamental issue: they don’t guarantee a unified source of truth. Why DeFi is more of a risk-shifting mechanism than a true alternative.
In my last article as part of the collaboration with The Securities Services Advisory Group (TSSAG), I covered Action-Based vs State-Based Systems.
This time I want to cover a rather broad topic: smart contracts. It is the continuation in a small series. I previously examined in part 2 how early expectations around smart contracts—conceptualized independently of blockchain—often ignore economic realities, particularly how new controls transform risk rather than eliminating them. While Bitcoin’s Nakamoto Contracts provided a foundation for decentralized agreements, their scope was intentionally narrow, enabling only trust-minimized applications such as escrow, time-locked transactions, and atomic swaps.
Ethereum’s Turing-complete smart contracts expanded these capabilities, but increasingly adding complexity to such an arrangement is neither economically feasible nor necessarily desirable. The trade-offs—oracle reliance, data constraints, and high execution costs—make certain applications impractical. Despite the narrative of decentralization, it features structural centralization in key areas. This narrative of decentralisation seems to exempt such arrangements from sufficient scrutiny leading to economic models that are more aligned with Soviet economic planning than a free market e.g. in the case of Ethereums ‘centrally planned gas model.’
The assumption that blockchain can fully replace traditional financial infrastructure (or even large parts of it) remains unconvincing. A distributed ledger is not a business application; it lacks business logic and integrated compliance, risk management, and structured workflows that financial institutions require. Rather than forcing unsuitable business scenarios onto blockchain, its constraints should shape realistic business and operating models that align with market needs.
The Devil is in The Detail
Much of the discourse around smart contracts is overly technical and lacks conceptual depth. Most discussions focus on infrastructure, leaving the operational, legal, and systemic questions unexplored. This creates misaligned expectations, design flaws, and barriers to adoption.
A blockchain like Ethereum provides snapshots of its state at fixed intervals (i.e., blocks). Relevant computation happens beforehand, and results are captured in the block records. This means the transaction to request external data and the oracle’s response must occur in separate blocks.
Oracle Interaction Requires Two Separate Transactions
Block 1: A user (EOA) sends a transaction to the smart contract (e.g.,
requestWeatherData()).Block 2+: The oracle (off-chain service) fetches the weather data and submits a new transaction.
Block 3+: The smart contract updates its state, making the data readable on-chain.
Compared to a traditional banking GUI, which queries a backend API in milliseconds, Ethereum's oracle model introduces an unavoidable delay (~36 sec) due to the blockchain's sequential transaction processing.
Ethereum Transactions and Gas Fees
Every action (whether sending ETH, interacting with a smart contract, or deploying a contract) is technically the same transaction type—an Ethereum EVM transaction.
Different business activities that would, in TradFi, be represented as different transaction types use only one message type in Ethereum:
ETH transfer (
send(ETH))Smart contract execution (
contract.functionCall())Contract deployment (EIP-1559 formatted transactions)
Gas fees apply to all transactions, even those that don’t transfer ETH.
There is no equivalent of SWIFT's MT categories (e.g., MT1xx for payments, MT5xx for securities, MT9xx for administrative messages).
The only distinction in Ethereum transactions is what the transaction does (e.g., ETH transfer, contract call, contract deployment), but the underlying message format is always the same.
SWIFT and ISO 20022 Lack a true equivalent to smart contract calls
SWIFT messaging follows a "send and process" model, not "execute function and return output" like a smart contract.
Every SWIFT message is either:
A transaction request/confirmation (e.g., MT 103, MT 202).
A statement or report (e.g., MT 548 for settlement status).
A free-format message (MT 599), which can contain custom instructions but is not automated.
The closest equivalent is perhaps a cancellation request or a camt.060 (ISO 20022 Account Reporting Request). It is similar to an API request, but not deterministic.
Banks ‘decide’ whether to respond.
Smart contracts execute immediately and deterministically once included in a block.
A CSD's rulebook is a policy, while a smart contract's rules are enforced at the protocol level.
We often say that a smart contract emits an event or records a request for an oracle to fetch data. But how does this actually work?
Ethereum is a Distributed System
Every Ethereum node stores a copy of the smart contract and validates all transactions by executing the smart contract code.
However, Ethereum cannot directly fetch external data (e.g., weather data, stock prices, FX rates).
Who or What Bridges the Smart Contract and the Oracle?
Oracles are off-chain services that monitor the blockchain for specific events.
When a smart contract logs an event or writes a request to storage, the oracle detects this by scanning new blocks.
The oracle is not "called" like an API—it simply observes on-chain activity and reacts accordingly.
How Does the Oracle Know the Request is Genuine?
In API authentication, systems exchange API keys to verify requests.
Ethereum does not have built-in authentication because smart contracts are public and deterministic—you cannot embed private keys without exposing them.
Instead, oracles verify the request’s validity based on predefined logic:
They check which contract made the request (e.g., whitelisting trusted contracts).
They validate input parameters (e.g., checking if the request follows an expected format).
They may use staking or reputation systems (e.g., Chainlink’s decentralized oracle network) to reject invalid or spammy requests.
How Does the Oracle Respond?
The oracle does not receive a direct message from the smart contract.
Instead, it monitors Ethereum blocks and detects transactions that include requests.
Once the oracle retrieves the off-chain data, it sends a new transaction back to Ethereum to deliver the response.
This response transaction triggers a callback function in the smart contract (e.g.,
fulfillTemperature()) to store the updated data.
For efficiency, Chainlink uses Off-Chain Reporting (OCR) to reduce gas costs. Chainlink Nodes sign their data off-chain and share it with other nodes. The aggregated data is sent to the blockchain by a single transaction. The signatures of all participating nodes are included in the on-chain transaction, proving their agreement.
Ethereum smart contracts cannot fetch external data for free
Unlike API calls in traditional systems, Ethereum smart contracts cannot fetch external data for free. Chainlink nodes require LINK tokens as payment for their services.
The cost varies based on:
The number of nodes (more nodes = higher security but also higher cost).
The data source (free vs. premium sources).
The request complexity (e.g., single price feed vs. multiple sources for aggregation).
In Ethereum, spamming the blockchain is always expensive because gas fees apply to every transaction. In Chainlink, every request also requires LINK tokens, so even if someone tries to flood the system, they must pay per request. If an attacker tries to flood the network with requests, the following safeguards apply:
Nodes may reject excessive requests.
APIs may throttle queries (e.g., limit queries per second).
Smart contracts may limit request frequency using time-based restrictions.
Developers must optimize oracle requests to avoid excessive costs. Using on-chain price feeds (Chainlink provides frequently updated data without needing a request) or implementing time-based rate limits (e.g., allow data updates only every X blocks) for example.
This is important consequences. Before interacting with a smart contract, you need to know whether it relies on Chainlink or another oracle provider, because this affects who pays and how the request is processed.
When a user calls a function that triggers an oracle request (e.g., requestWeatherData()), the smart contract deducts LINK from its balance. The user pays the Ethereum gas fee for the transaction but does not directly pay LINK. The smart contract, not the user, actually transfers LINK to the Chainlink network. This creates another grey-zone of uncertainty when it comes to sanction screening. Who are you screening against: the smart contract address or the actual receiver which is not the smart contract. Instead of sending LINK per request, a smart contract could:
Accumulate multiple oracle requests in storage.
Bundle them into a single Chainlink transaction
Let the oracle fulfill multiple data points at the same time.
The direct relationship between sender and receiver is thus abstracted away.
If you call a smart contract that requires LINK to pay for an oracle request, but the contract lacks sufficient LINK, the transaction will fail—and you will still lose your gas fee.
Even though Ethereum's execution is deterministic, the overall process that includes oracles is not, which undermines the deterministic execution argument often used to justify smart contract superiority.
Given the same inputs and the same state, Ethereum smart contracts always produce the same output. This is because every Ethereum node validates transactions independently.
Chainlink Oracles Introduce Non-Determinism
Oracles do not execute on-chain deterministically—they are off-chain actors that:
Observe blockchain events asynchronously.
Fetch data from external sources (which may change unpredictably).
Decide when and how to respond based on their network conditions, fees, or availability.
Why Did Ethereum Choose Oracles Instead of a Built-In Solution?
Ethereum’s blockchain has three core constraints that make direct external data fetching impossible:
1. All Nodes Must Have the Same State at the Same Time
Blockchains are synchronized distributed ledgers, meaning all nodes must maintain an identical state.
If one node fetches real-world data (e.g., the latest BTC price) while another fetches a slightly different value at the same time, consensus would break.
The only way to solve this natively would be to force all nodes to rely on a single centralized oracle, which introduces a centralization risk Ethereum was designed to avoid.
2. No Native Way to Determine the Sequence of External Updates
If multiple nodes were allowed to fetch external data directly, there’d be no consistent order of updates.
Example Problem:
One node retrieves BTC = $60,000 at 10:00 AM.
Another node fetches BTC = $59,900 at 10:01 AM.
The network has no way to determine which price is "correct" because ordering external events is not possible on-chain.
This means that unless all nodes agree on the same external input at the same time, the blockchain cannot deterministically process external data.
3. Blockchains Can’t Initiate External Actions
Ethereum smart contracts are passive—they only execute when a transaction triggers them.
If Ethereum wanted real-time external data, it would need to continuously poll APIs, which isn't possiblebecause:
Gas fees make continuous execution infeasible.
Transactions must be externally triggered—Ethereum cannot self-execute without input.
Solution: Instead of Ethereum fetching data, off-chain oracles monitor blockchain events and respond with data when needed. The overall issue has not been solved though, it got brushed under the carpet.
But the Problem Isn’t Solved—It’s Just Moved to the User
Ethereum’s design lets the blockchain ignore the external data problem.
Instead, users (dApps, businesses, developers) now bear the complexity of handling unreliable oracles.
Users must now decide:
Which oracles to trust (centralized vs. decentralized, reputation-based vs. permissionless).
How often to refresh data (optimizing between cost, accuracy, and availability).
How to handle delays and failures (e.g., what happens if an oracle is slow or manipulated?).
This shifts the risk and burden away from Ethereum itself and onto dApp developers, businesses, and users, forcing them to navigate:
Security risks (oracle manipulation, single points of failure).
Economic risks (paying for unreliable or costly oracle services).
Regulatory risks (who is responsible for bad data?).
Why Oracles Undermine the Blockchain as a "Single Source of Truth"
A blockchain is often described as a single source of truth, but this assumption breaks down when external data is introduced. Since a blockchain cannot verify external data, it inherits the errors, biases, or manipulations of the off-chain sources feeding it.
1. Oracles Cannot Guarantee Truth—Only Accuracy to Input
If an external data source provides false or manipulated information, the oracle faithfully delivers the incorrect data to the blockchain.
Example:
An API falsely reports ETH/USD = $500 when the actual price is $1,500.
Chainlink will correctly deliver $500 to smart contracts—but that value is still wrong in reality.
The oracle guarantees data integrity (accurate transmission), but not data validity (correctness of information).
2. Chainlink Minimizes but Does Not Eliminate Risk
Chainlink cannot independently verify whether an input is true—it can only ensure consistent aggregation of multiple sources.
To reduce risk, Chainlink relies on:
Data aggregation (pulling from multiple providers).
Reputation systems (evaluating oracle performance).
Staking incentives (punishing misbehavior).
However, these mechanisms do not cryptographically verify the original data sources—they only improve redundancy and resilience.
3. Traditional Finance Uses Redundant Verification Layers
Banks consume prices from multiple providers (e.g., Bloomberg, Reuters) to cross-check and ensure accuracy.
Regulatory requirements mandate strict checks and balances for price feeds to prevent insider trading and price manipulation.
These are centralized processes, relying on institutional trust rather than cryptographic guarantees.
4. External Data Lacks Cryptographic Proof, Making it Manipulable
Most data providers (e.g., stock exchanges, weather stations) do not sign their data with cryptographic proofs.
This means any API-based oracle system remains vulnerable to false or manipulated data.
5. A Possible Solution: Signed Data Feeds
If data providers cryptographically signed their data using private keys, oracles could verify the signaturebefore submitting data on-chain.
Example:
Nasdaq cryptographically signs its price feed.
Chainlink nodes verify the signature before delivering the data.
This ensures:
The data originates from the claimed provider.
It has not been altered in transit.
This approach would make oracles more secure and reduce trust assumptions.
6. Chainlink Centralization Risks: Too Many Responsibilities in One System
Chainlink nodes are responsible for multiple functions:
Fetching data (pulling prices from external sources).
Determining price truth (aggregating sources).
Providing data to contracts (final on-chain delivery).
This consolidation of responsibilities is a centralization risk.
While Chainlink mitigates this risk through decentralization and redundancy, it does not fully eliminate it.
Smart Contracts Operate Independently—Leading to Conflicting Data
While Ethereum ensures transaction determinism within a single smart contract, it does not guarantee global data consistency across different contracts.
1. Each Smart Contract Operates in Isolation
Each smart contract has its own logic and data storage.
Contracts do not share a global memory space—they interact only through explicit transactions.
This means:
Two smart contracts querying different oracles will naturally get different results.
Even if they query the same oracle, timing differences or aggregation rules can lead to conflicting data.
2. Blockchain Nodes Are Deterministic, But the System as a Whole Is Not
Every Ethereum node independently verifies transactions and arrives at the same computational output.
However, the system as a whole can still have inconsistent data across contracts because:
Different smart contracts use different oracles or price feeds.
Timing differences: A contract querying at Block N may get a different result than one querying at Block N+1.
Aggregation differences: Oracles use different data sources, sampling methods, and weightings.
3. Conflicting Data in the Same Block is Possible
Even within the same block, two contracts can settle transactions using different prices if they reference different data sources.
Example:
Contract A queries Oracle X at Block 100 → Price is $2,000.
Contract B queries Oracle Y at Block 100 → Price is $1,990.
Both results are "correct" within their own context, but they contradict each other globally.
4. The Illusion of Global Consistency
Ethereum’s consensus model ensures every node computes the same transaction the same way.
However, it does not enforce global consistency of off-chain data.
The entire system remains fragmented:
Different DeFi platforms may use different oracles and reference different price feeds.
This causes price discrepancies across protocols, leading to MEV (Maximal Extractable Value) and arbitrage opportunities.
Why Traditional Finance Ensures a Single Source of Truth, and Why Blockchain Doesn’t
1. TradFi’s Model: Controlled, Canonical, and Isolated Data
In centralized financial systems, a single entity ensures that there is one source of truth for pricing, ownership, and instrument data.
Examples:
Bloomberg, Reuters, or internal broker evaluations act as the primary pricing authorities.
Each financial instrument is uniquely identified (e.g., via CUSIP, ISIN).
Metadata specifies the vendor or source (e.g., "CUSIP 123 from Bloomberg, sourced from Exchange X").
Even when alternative data sources exist, they are:
Strictly isolated (not propagated system-wide).
Marked as secondary and not mixed into the primary dataset.
Reconciled separately to maintain global consistency.
2. Why Blockchain Fails at This Model
Ethereum allows multiple versions of truth to exist simultaneously.
Unlike TradFi, Ethereum does not specify which price is canonical or how to resolve discrepancies.
Examples of conflicts:
Two different oracles provide different ETH/USD prices at the same block height.
The blockchain stores both values as cryptographically valid, even if they contradict each other.
There is no built-in mechanism to say, "This price is authoritative, and this other price is secondary."
This means that financial applications requiring strict consistency cannot function reliably on Ethereum.
3. The Lack of Interpretative and Control Layers in Blockchain
Traditional financial systems distinguish between raw data and its interpretation.
Ethereum smart contracts directly consume raw data (e.g., $5 or $6) but do not specify:
Which data is canonical or alternate.
Whether a discrepancy exists or should be reconciled.
How downstream systems should interpret conflicts.
This is because Ethereum only validates the structural integrity of a block, not the economic consistency of its contents.
4. The Consequences of Mixing Verified Processes with Unverified Inputs
Ethereum enforces deterministic execution of transactions but does not verify the correctness of external data inputs.
This mixing of verified and unverified data creates hidden inconsistencies that only external observers can detect.
Example:
A DeFi lending protocol might use Oracle A for ETH/USD while another uses Oracle B.
Both protocols operate correctly based on their own data, but system-wide, a price inconsistency creates financial risk (e.g., arbitrage, forced liquidations, or exploit vulnerabilities).
Blockchain is trust-minimized for transaction execution but not for data integrity.
5. Why This is Why DeFi Works, and Why It Won’t Work for TradFi
DeFi can function despite these inconsistencies because it is a parallel system:
Users understand that pricing is dynamic and may differ across platforms.
Market participants are incentivized to arbitrage price differences.
There is no formal obligation for any data to be absolutely correct.
TradFi cannot tolerate this model:
Financial regulations require authoritative data sources and reconciliation.
Institutions must prove data accuracy for compliance and risk management.
Systemic risk arises if discrepancies cannot be controlled or identified.
Ethereum’s lack of abstraction, interpretative control, and reconciliation layers means it is fundamentally unsuited for mission-critical financial infrastructure.
While blockchain excels in decentralization and transparency, it fails where absolute certainty, structured governance, and deterministic economic consistency are required.
Why Blockchain Fails as a Unified Source of Truth for Smart Contracts
Blockchain's true strength lies in recording immutable state changes, not in resolving conflicting truths. The lack of standardized metadata that qualifies external data (e.g., price types, sources, methodologies) introduces ambiguity, which can lead to financial and legal disputes.
1. The Problem: Lack of Metadata Creates Ambiguity
Traditional financial data feeds include structured metadata to clarify:
Who provided the data (e.g., Bloomberg, Reuters, exchange order book).
What the data represents (e.g., end-of-day price, live trading price, auction price).
When it was retrieved (timestamped to the millisecond).
Where it originated (exchange venue or reporting entity).
How it was calculated (VWAP, TWAP, midpoint, etc.).
Example of Proper Metadata for a Price Feed:
"source": "Bloomberg Terminal API",
"time": "2025-01-21 16:00 UTC",
"type": "End-of-day price",
"methodology": "Volume-weighted average price (VWAP)"
Ethereum smart contracts lack this level of data qualification, leading to situations where:
Multiple contradictory price points exist with no differentiation.
There is no native way to reconcile which price is "correct."
Smart contracts ingest raw values without awareness of their context.
2. The Fundamental Oversight: No Reconciliation Mechanisms
Because blockchain lacks schema standards, developers assume the absence of visible conflicts means correctness—but this is an illusion.
Without reconciliation mechanisms, different contracts referencing different data sources:
May process transactions based on different price realities.
Cannot cross-verify or resolve discrepancies.
Create hidden systemic risks (e.g., liquidations based on conflicting price feeds).
DeFi relies on arbitrage to fix inconsistencies, but TradFi relies on governance and reconciliation.
TradFi ensures data quality before it reaches financial systems.
DeFi assumes price discrepancies are normal and lets the market sort them out.
This fundamental difference makes blockchain a weak fit for financial infrastructure requiring certainty.
3. Potential Solutions: Governance & Reconciliation Mechanisms
Establishing governance structures and reconciliation processes would:
Allow for decentralized conflict resolution.
Ensure that financial contracts reference standardized, agreed-upon data points.
Provide the level of certainty required for institutional adoption.
However, these solutions must be designed to preserve decentralization, rather than introducing a centralized entity as the ultimate arbiter of truth.
4. Looking at Alternatives: DAML’s Approach and Its Limitations
DAML (Digital Asset Modeling Language) offers a partial solution by:
Enforcing data sovereignty (defining which parties can access and modify data).
Codifying shared workflows into executable schemas (providing some structure for reconciliation).
However:
DAML is still use-case specific—it doesn’t enforce global consistency across smart contracts.
Its JSONB-based ledger format lacks inherent reconciliation mechanisms between external data sources.
Its bilateral approval system (where two counterparties must approve changes) relies on subjective decision-making rather than deterministic validation.
While DAML introduces data governance, it does not solve the problem of universal truth in decentralized systems.
Ethereum Suffers From a Structural Issue Preventing it from Guaranteeing a Unified Source of Truth
Let’s say three different price feeds are available on Ethereum:
BTC/USD Oracle → $40,000
BTC/ETH Oracle → 20 ETH per BTC
ETH/USD Oracle → $1,900
These values should be mathematically consistent, meaning
In this made up example, there is an inconsistency because BTC/USD = $40,000, but the implied rate from BTC/ETH × ETH/USD is only $38,000. You can observe these kind of examples on Ethereum so it’s not a theoretical issues. This creates abnormal arbitrage opportunities and distorted DeFi lending liquidations, where some positions may liquidate unfairly based on inconsistent prices.
Blockchain systems assume the data they receive is correct if it adheres to protocol rules.
They don’t validate:
Whether the data makes actual sense in the real world.
Whether interdependencies between inputs are consistent and don’t account for circular dependencies
The inability to handle relational truths and circular dependencies is a critical blindspot in blockchain design. While blockchains excel at deterministic, on-chain logic, they struggle with interdependent or externally derived data, often creating "truths" that aren’t verifiable. The issue of price inconsistencies hasn’t been widely discussed or explicitly identified as a systemic issue in blockchain and cryptocurrency literature. However, related topics have been addressed in terms of market inefficiencies, volatility spillovers, and discrepancies in price discovery mechanisms. But such discussions are debating symptoms not the root course.
Ethereum and DeFi do not function as a single integrated system but rather as a collection of loosely connected, independent and siloed applications that interact only when explicitly triggered. This results in a ‘Verschiebebahnhof’, where value, risk, and inconsistencies constantly shift between protocols rather than being systematically resolved.
The German word "Verschiebebahnhof" literally translates to "shunting yard" in English, referring to a railway yard where train cars are rearranged by being decoupled, moved, and reattached to different trains.
However, in a figurative sense, especially in economic, bureaucratic, or systemic discussions, "Verschiebebahnhof" is used metaphorically to describe a system where things are not actually resolved but merely shifted around, much like how railway cars are shuffled between tracks without necessarily reaching a final destination.
This creates another effect. While blockchain transactions are immutable, legal and economic disputes are not necessarily final—especially when a real-world counterparty exists who can be identified and held responsible.
If a DeFi protocol (e.g., a DAO-run lending platform) incorrectly liquidates positions due to a faulty oracle feed, the blockchain records are immutable, but liability is not: Such precedence exists e.g. MakerDAO Black Thursday (2020):
Due to oracle failures, some vaults were liquidated at near-zero bids.
Users took legal action, and MakerDAO’s governance voted to compensate affected users.
The more you look at the detail of what such arrangements entail the more problematic it becomes. Take for example the reliance on wallets (like MetaMask) to abstract complex smart contract interactions (e.g with dApps like Aave) for users.
You Stake ETH and Receive a Wrapped Token
You provide ETH to Aave's liquidity pool.
Aave mints aETH (Aave-wrapped ETH) or a similar derivative token.
This aETH represents your staked position and accrues interest over time.
You Want to Withdraw Your ETH
You go to Aave's frontend (app.aave.com).
You click "Withdraw" and MetaMask initiates a transaction request.
Aave’s backend generates a transaction payload, which MetaMask prompts you to sign.
MetaMask Asks You to Sign the Pre-Filled Transaction
The withdrawal request is formatted as a call to the smart contract.
Aave prepares the transaction data (e.g., function call, parameters).
MetaMask does not validate if the pre-filled data is "correct"—it just displays it for you to sign.
If Aave goes offline, the withdrawal process is much harder—you’d need to manually construct the smart contract call. Users must trust that the Aave dApp is formatting the withdrawal transaction correctly—if it includes an incorrect function call, the user might sign something unintended. And if it was so easy to validate it then you wouldn’t need Aave’s help to construct the message in the first place. Most users are unable to verify whether Aave’s suggested transaction is "correct" without advanced skills. I would say it requires an awful lot of trust that Aave or any other protocol is not a crook.
MetaMask assumes users know what they are signing.
It does not check whether Aave’s contract call is legitimate, well-priced, or optimal.
If Aave introduced an unnecessary extra fee, users wouldn’t notice unless they checked manually.
DeFi is Not a Unified Financial System—It’s a Risk-Shifting Mechanism
DeFi is often marketed as a parallel financial system, but in reality:
It does not manage risk—it only shifts it between participants.
It does not enforce a single source of truth—it allows conflicting realities to coexist.
It does not protect users from systemic failures—it makes them responsible for absorbing losses.
It does not provide financial finality—each protocol enforces its own isolated outcomes.
This isn’t necessarily bad, but it means that DeFi is fundamentally different from TradFi, and it cannot replace traditional finance and make it better. It can replace traditional finance with something different that may or may not be better depending how we think of these consequences.
The problem with tokenization for financial instruments is that it would require a solution to these issues—or at a minimum, an acknowledgment that they exist but will be accepted under the assumption that users will go along with it. If that’s not the case, and banks were to try to fix it, it creates an even bigger problem: investing in something, such as relational data consistency, that doesn’t directly translate into customer benefits (only indirectly). However, banks don’t like that because power and influence are tied to control over client revenues, not efficiencies at the core of the bank. The market lacks incentive structures to fix this issue. Taken all together, it makes me rather skeptical of how tokenization is currently being approached.
And yes, there are more issues but I am running out of space (as the Substack app won’t stop reminding me) and have to stop here. My point is: Before telling us that tokenization will revolutionize finance, first explain how you will solve these structural contradictions—because so far, nobody has.
For part 4:
