Chapter 3

New Railways

When the railway swept through Europe in the 19th century, everything changed. Goods that had previously taken weeks to transport by horse and barge could now travel in days. People could cross the entire continent without changing mode of transport at every river or mountain range. But the new infrastructure was chaotic: different countries and companies used different track gauges, their own standards and incompatible systems. At some borders, goods had to be lifted from one wagon to another, simply because the rails did not match.

In many ways, today’s financial system finds itself at a similar turning point. The internet has already made it possible for us to meet in time and space, almost irrespective of geography. We can hold video meetings with colleagues on the other side of the world, collaborate in real time in cloud documents and stream music from data centres we never see. But when money is to be moved – when value is to travel between individuals, companies and countries – we are still largely running on the banking railways of the 20th century.

The traditional “tracks” are called SWIFT, correspondent banks, central bank settlement systems and card networks. They are robust, regulated and proven – but also slow, fragmented and full of intermediaries. An international payment can still take days, pass through several banks and cost percentage-based fees, even though the messages describing the payment themselves travel across the internet in a fraction of a second. The internet is our digital continent, but money is transported as if we still had the telegraph and the steam locomotive.

When Bitcoin appeared, it was like a single, new railway line. It was slow, simple and focused on one thing: moving value globally without a central operator. You can think of Bitcoin as a robust goods train: it does not travel fast, it does not travel often, but it arrives – and the whole world can see exactly which track it took. Every block is a wagon of transactions; the entire chain is the history of where the trains have gone. For the first time, two parties could send money directly over the internet without asking a bank’s permission, and still get strong guarantees that the transaction was valid and irreversible.

But just as the first railway lines were not enough to cover every need – local traffic, long-distance traffic, goods trains with different loads – a single blockchain was not enough for every type of digital commerce. Bitcoin was excellent for holding value and making relatively few, large transactions. It was less suited to carrying complex agreements, high-frequency micro-payments or millions of interactions per second. The need for more “tracks” grew.

With Ethereum came the next step: not just a new line, but a line where you can attach new kinds of wagons. The ERC20 standard became like a standardised goods wagon that anyone can load their own objects into – tokens representing everything from other currencies and share-like instruments to loyalty points and in-game currencies. All these wagons can roll on the same rail: the Ethereum network. It created a kind of economic ecosystem where thousands of projects could share the same infrastructure, with the same base rules, but with entirely different content.

Soon it became clear that even the Ethereum rail would become congested. As more and more wanted to run their trains – decentralised exchanges, games, lending protocols – the tracks filled up, and ticket prices (transaction fees) rose. The solution was to build layer-two networks, side tracks and new lines that relieve the main line without breaking its security model. This is where networks such as Arbitrum One, Optimism, Base, Xlayer and Unichain come in.

You can see them as high-speed tracks laid on top of the same continent. They are designed to handle more and faster transactions at lower cost, but final settlement still takes place on Ethereum’s main chain. Trains can run at high speed on these side tracks, load and unload goods, and at regular intervals “sync” their actual load back to the main line. For the user, it is noticed mainly as cheaper and faster transactions. For the system as a whole, it is a trade-off: you retain much of the security of the main chain, but rely on more complex technology and more assumptions about how operators behave.

Networks like Polygon have chosen a slightly different role: they build a regional network with bridges into the great main lines. Polygon offers both its own chain and infrastructure solutions that make it easy to build applications that feel fast and cheap, but which can still speak to the Ethereum ecosystem. It is like having a denser, regional railway network around a big city, where commuter trains and local goods trains run frequently and cheaply, but where you can always change to the long-distance train at the central station.

At the same time, entirely new railway companies are being born with their own technology, their own track gauge and their own promises of speed and capacity. Solana, Aptos, Sui and Monad are trying to build their own high-speed lines from the ground up. They experiment with new ways of ordering transactions, parallelising computations and compressing data. The result is chains that can handle thousands, sometimes tens of thousands, of transactions per second, with very low fees. But just as with historical railway networks, this involves new trade-offs: hardware requirements rise, the number of full nodes may fall, and the debate about how decentralised these networks really are becomes more intense.

Avalanche takes a different angle with its C-chain and its subnets: a multi-track system where different chains can be tailored to different purposes, yet connected to a common security layer. Companies or institutions can in principle lay their own “private line” – a chain with its own rules, participants and permissions – while still having bridges to the public infrastructure. It resembles how some industrial companies historically built their own tracks into their factories, connecting to the national network at a few strategic junctions.

On all these digital railways, goods are transported. But the goods are no longer coal, timber or people, but information and value. ERC20 tokens carry representations of money, bonds, fund units, game objects and rights. Smart contracts work as automatic loading cranes, contract text and bookkeeping systems in one: they can receive payments, distribute profits, manage collateral or pay out insurance when certain conditions are met. Decentralised exchanges are the new marshalling yards, where thousands of assets change owner every minute, entirely coordinated by code.

Meanwhile, the old banking railways remain – and are noticing the competition. Compare an international bank transfer via SWIFT, which can take days and cost percentage-based fees, with a stablecoin transfer on a fast chain like Solana or via an L2 on Ethereum: there, the same amount can reach the recipient in seconds, at a cost of a few cents. For an ordinary consumer in Sweden, it is noticed mostly in niche cases. For a company sending payments across several continents, or for a migrant worker sending money home every month, the difference can be dramatic.

But the lead is not without drawbacks. The digital railways are younger, more experimental and less regulated. Bridges between chains – the digital equivalents of transhipment hubs – have historically been vulnerable points where large amounts have been lost in attacks. User interfaces are often technical and difficult for non-experts. And the question of liability is diffuse: who bears responsibility if something goes wrong in a global, permissionless network without a central operator?

There is also another parallel to the railway history of the 19th century: the war of standards. Back then it concerned track gauge and coupling mechanisms. Today it concerns programming models, virtual machines and security models. EVM-compatible chains (Ethereum, Arbitrum, Optimism, Polygon, Base, Xlayer, etc.) represent a kind of de facto standard: the same “track gauge” on many lines. Others, such as Solana or Aptos/Sui with the Move language, choose their own standards that offer higher capacity or other properties – but require locomotives and wagons to be specially adapted. Bridges, compilers and cross-chain protocols become today’s transhipment stations, where cargo must be translated between standards, with all the costs and risks that entails.

In the middle of all this stand states and central banks. They watch private actors redraw the map for value transport and ask themselves: should we build our own rails, or connect to those that already exist? Projects like the digital euro and the e-krona often explore their own, more closed chains – permissioned networks where only approved participants may run trains, and where regulation, traceability and control are built in from the start. In some visions, these state digital currencies can still be linked to public chains via bridges; in others they are kept entirely separate, like state high-speed trains alongside the private lines.

This leaves us with a few decisive questions. Who will, in the long run, own the rails of the digital economy – public, open networks where no one has a monopoly, or state/private controlled chains? Who captures the most value: the one who builds the infrastructure, the one who loads on goods (tokens, assets), or the one who operates the stations and platforms where people actually interact? And what happens when one and the same transaction perhaps rolls through several different systems: an e-krona converted to a stablecoin on an L2, which is then swapped for a token on Solana?

“Digital railways for commerce” is the story of how blockchain technology has gone from a single, experimental line to a whole network of competing tracks – and how these tracks challenge, complement and sometimes merge with the banks’ old railways. In the next chapter you can let the trains be filled with concrete cargo: DeFi, stablecoins and tokenisation – the new economic models that use these railways to build a financial market no longer tied to a single nation or bank.

Case study

Imagine you are CFO of a medium-sized Swedish company selling machinery to customers in Latin America. You are to be paid 250,000 euros for a delivery to a company in Brazil. We follow the same deal in two ways: first on the old banking rail, then on a modern blockchain rail.

Scenario 1: The old rail (SWIFT, correspondent banks, securities via custodians)

Step 1 – The invoice and the instruction

You send the invoice: EUR 250,000, payment within 10 days, to your company account in Sweden. The invoice states: IBAN of your euro account; BIC/SWIFT code of your Swedish bank; the bank’s address. The Brazilian customer goes to their local bank, submits the payment order and states that the money is to be sent in euros to your IBAN. The bank performs an initial compliance check: KYC on the customer, purpose of the payment, sanctions screening.

Step 2 – The correspondent chain

The problem: your customer’s bank has no direct relationship with your Swedish bank’s euro clearing. The payment therefore goes via one or more correspondent banks: the customer’s bank in Brazil debits the customer’s account in BRL and sells BRL against EUR internally or via a partner; the bank sends a SWIFT message to its correspondent bank in Europe: “send EUR 250,000 onwards to this recipient in Sweden”; the correspondent bank in turn sends a new SWIFT message to your Swedish bank’s euro correspondent, or directly to your bank. Each link performs: sanctions screening; AML screening (money laundering); charging its own fees. None of them “moves physical money”; they adjust balances in their internal systems and in the central banks’ settlement systems.

Step 3 – Time passes

From your perspective: Day 0: the customer says “we have paid”. Days 1–2: nothing appears in your account. You ask your Swedish bank to check. Days 2–4: the money passes through the correspondent bank, perhaps getting stuck in a manual review if the payment text triggers some rule. Days 3–5: the amount lands in your euro account. You see the deposit, often with fairly cryptic sender information. In the meantime: at least 2–3 banks have looked at the transaction; each link has taken its fee (either upfront from the customer, or deducted from the amount that arrives); you have had uncertainty: when will the money arrive, will compliance stop it, will the amount be reduced by fees?

Step 4 – The securities transaction (if you invest)

Say you want to place EUR 100,000 of the liquidity in a corporate bond listed in Germany. The path looks like this: you call/email your bank or use their custody service; the bank places an order on the German market via its broker; once the trade is done, ownership is registered in: the CSD (central securities depository) in each country, and your bank’s internal systems (your custody account shows the holding). Settlement takes place T+2: two days later ownership formally transfers, and the money is debited from your account. You never see the underlying infrastructure – only an entry in your custody account. Legally, you often own a claim against your bank/securities institution, which in turn has a claim on the next link, and so on.

Scenario 2: The new rail (blockchain, stablecoins, tokenised securities)

Now we take the same deal, but both you and your customer use a modern blockchain infrastructure. You have agreed to use an established euro stablecoin on a chain like an Ethereum L2 or Solana, and the bond you want to buy exists as a tokenised security on the same chain.

Step 1 – The invoice and the address

The invoice looks different: Amount: 250,000 “EURC” (a regulated euro stablecoin). Payment address: a wallet address on the chosen chain (your company wallet controlled by your treasury department, with strong security). The customer in Brazil already has an account with a regulated on-ramp (e.g. a local fintech) where they can: pay in BRL via local bank transfer; exchange BRL → EURC on the chain.

Step 2 – The payment on the chain

When the customer is ready: the customer buys 250,000 EURC on their on-ramp; EURC lands in their company wallet. They open their wallet and send 250,000 EURC to your address. The transaction propagates across the network, is validated and included in a block. On a fast chain: confirmation within seconds; transaction fee: a few cents. You can see in real time: that the transaction exists; that it contains precisely 250,000 EURC; that your address has now increased by that amount. No correspondent chain, no uncertain wait of days.

Step 3 – Accounting and risk

You book: a receivable now replaced by 250,000 EURC in your company wallet. The counterparty risk moves from a chain of banks to: the issuer of EURC (can they redeem 1:1 against real euros?); the technical security of the chain; your internal key management (if you lose the private key, the asset is gone). But you: know exactly when the payment was secured; can see directly, transparently, that the amount is correct.

Step 4 – Securities as tokens

Now you want to buy the equivalent bond exposure – but as a tokenised security on the chain. Your treasury department logs into a regulated platform for tokenised securities (which requires KYC and company registration). The platform shows a bond “ACME Corp 3.5% 2029” as an ERC20-like token (e.g. “ACME29”), where each token corresponds to EUR 1,000 nominal. You buy 100 ACME29 tokens for a total of 100,000 EURC. Technically this happens: you sign a transaction where 100,000 EURC is sent from your address to the issuer/market maker; at the same time 100 ACME29 tokens are sent to your address; everything happens atomically in a smart contract: either both transfers are carried out, or neither. The settlement is: near-immediate (seconds to minutes); transparent: anyone can see that your address now holds 100 ACME29 tokens; final: there is no T+2 with intermediate credit risk in clearing houses. Legally, the set-up can vary: either the platform registers you as direct owner in an underlying register, and the token is merely a technical representation; or the token itself is the proof of ownership, with rights built into the agreement. But the infrastructure – the railway itself – is the blockchain.

Step 5 – The comparison in practice

Time

Old rail: payment 2–5 banking days; securities T+2, sometimes longer across borders. New rail: payment seconds–minutes; securities in practice T+0, as soon as the block is confirmed.

Cost

Old rail: several links with fees (sender bank, correspondent, receiving bank); hidden currency mark-ups. New rail: network fees in the cent range; spread/fees at on/off-ramps and platforms, often more transparent.

Transparency and traceability

Old rail: you see “payment on its way” mostly as text in a banking system; traceability requires manual enquiry between banks. New rail: all transactions are open; you can yourself verify that money and security tokens have changed address; the audit trail is built into the infrastructure itself.

Risk profile

Old rail: credit and counterparty risk spread over several banks and CSDs; strong regulation, deposit guarantees, established case law. New rail: technical risks (smart contracts, chain security); issuer risk for stablecoins and securities issuers; greater operational risk if you lack good security around keys and internal processes.

In practice, many companies will for a long time use both systems in parallel: the old banking rail where regulation, insurance and processes are well established, and the new digital railways where speed, transparency and flexibility make certain types of deals decisively smoother.