Blockchain for Enterprise: What Actually Worked at Fidelity and RBS

By Gaurav Pratap Singh  ·  March 2026  ·  ~11 min read
Blockchain Ethereum Enterprise Solidity Hyperledger

Between 2016 and 2020, I built Ethereum DApps in production at two major financial institutions — Fidelity Investments and Royal Bank of Scotland (NatWest). This was during the first serious wave of enterprise blockchain adoption, before the hype cycle peaked and before most organizations got realistic about what distributed ledger technology actually solves.

Most blockchain content is either breathless hype (“blockchain will disrupt everything”) or breathless dismissal (“blockchain is just a database”). This is neither. This is a practitioner’s account of what actually worked, what failed, and what I think the honest enterprise blockchain landscape looks like in 2026.

---

The Fidelity Shark Tank DApp: What We Built

At Fidelity Investments, I built an Ethereum-based DApp for automating transfer-of-asset workflows in wealth management. The problem it solved: traditional securities transfer between custodians involved a settlement cycle of T+2 or T+3 (two or three business days). The workflow required manual reconciliation between multiple parties, paper trail verification, and custodian-to-custodian messaging that was slow and error-prone.

The DApp replaced this with an on-chain settlement workflow using Solidity smart contracts, Web3.js, Truffle for contract management, and a Spring Boot backend. The result: settlement time dropped from 3 business days to near real-time. This project won Fidelity’s internal Shark Tank competition and influenced the enterprise blockchain strategy.

What made this a good blockchain use case:

• Multiple parties who don’t trust each other — custodian A and custodian B have no shared infrastructure and no reason to trust each other’s data. A smart contract enforces the rules neutrally.
• Elimination of a trusted intermediary — the traditional workflow required a clearing house to intermediate. The smart contract replaced the clearing house’s role at a fraction of the operational cost.
• Auditability as a first-class requirement — every state transition on-chain is immutable and timestamped. This was a regulatory requirement that blockchain fulfilled naturally.
• The parties agreed on the smart contract terms — before deployment, all parties agreed to the contract logic. This is the governance step that most blockchain projects skip and then fail over.

What I would do differently:

• Smart contract upgradability from day one. We deployed immutable contracts and then had to redeploy and migrate state when requirements changed. The proxy pattern (UUPS or Transparent Proxy) should be in the design from the start, not retrofitted.
• Formal verification of critical contract logic. Tools like Certora Prover or Echidna for fuzz testing didn’t make it into our stack. For value-bearing contracts, they should be mandatory.
• Gas cost modelling before deployment. We underestimated gas costs on the Ethereum mainnet and had to rethink the transaction batching strategy after live usage showed costs were 3x our estimate.

The RBS Blockchain Training Group: Teaching Enterprise Engineers to Think Differently

At Royal Bank of Scotland (NatWest), I founded and led the RBS Blockchain Training Group — a programme that coached 15+ engineers on Ethereum and Hyperledger Fabric over several months. Running these sessions taught me as much about blockchain adoption barriers as the technical work did.

The hardest thing to teach: decentralized systems require a fundamentally different mental model. Enterprise engineers are trained to think in terms of a trusted central authority — the database is the source of truth, the system owns the data, consistency is enforced by the application. Blockchain inverts all of this. The ledger is the source of truth, no single party owns the data, and consistency is enforced by the network consensus protocol.

Until an engineer genuinely internalizes this inversion, they will design blockchain systems that fight against the technology. I saw engineers try to build traditional CRUD applications on Ethereum, adding a private key per “user” the same way they would add a user ID to a database. This is exactly backwards — in Ethereum, the user controls their own private key; the application does not hold it.

What actually clicked for engineers in the training:

• The analogy of a vending machine vs a lawyer. A smart contract is like a vending machine — you put in the right inputs and get the right outputs, guaranteed, without trusting the owner of the machine. This lands better than technical descriptions of consensus protocols.
• Live Truffle/Hardhat demos on a local Ganache chain. Engineers who could see a contract deploy, call, and emit events on their local machine in 10 minutes went from skeptical to engaged instantly.
• The trade finance proof-of-concept. Showing a working Spring Cloud + Ethereum system that processed letters of credit between two bank entities — without a central clearing bank — made the value proposition concrete.

Ethereum vs Hyperledger Fabric: The Enterprise Tradeoffs Nobody Admits To

Factor	Ethereum (Public)	Hyperledger Fabric (Private)
Permissioning	Permissionless (anyone can join)	Permissioned (membership controlled)
Transaction privacy	Public by default (use L2 for privacy)	Private channels between participants
Smart contract language	Solidity (EVM-based)	Chaincode: Go, Java, or Node.js
Transaction finality	Probabilistic (confirmations)	Deterministic (immediate finality)
Operational overhead	Low (managed by the network)	High (you manage the nodes)
Gas costs	Real costs (ETH), variable	No gas (internal network)
Best for	Cross-industry consortia, DeFi, open ecosystems	Closed industry consortia, supply chain within known partners

The mistake I saw most often: enterprises choosing Ethereum for internal use cases where they controlled all the participants. If you control who is in the network, you don’t need Ethereum’s permissionless design — you’re just paying gas costs for something Hyperledger Fabric does better. And if you’re using Hyperledger Fabric but your participants don’t trust each other and can join/leave freely, you’ve chosen the wrong tool for an open ecosystem problem.

Smart Contracts Are Still a Footgun in 2026 — Audit Accordingly

Solidity has improved significantly since 2016 — the compiler is better, the tooling (Hardhat, Foundry) is mature, and the ecosystem has produced robust patterns (OpenZeppelin’s contract library, EIP standards). But the fundamental challenge remains: a smart contract is immutable code that controls real value, and bugs in it cannot be rolled back.

The attack classes that have cost the most in production deployments:

• Reentrancy attacks — the DAO hack ($60M, 2016) exploited a contract calling external contracts before updating its own state. The fix is always: update state before making external calls. The Checks-Effects-Interactions pattern is non-negotiable.
• Integer overflow/underflow — largely mitigated by SafeMath (pre-0.8) and native overflow checking (Solidity 0.8+). But upgrading contracts that predate 0.8 is still a risk surface.
• Access control mistakes — functions that should be owner-only left public. OpenZeppelin’s Ownable and AccessControl patterns eliminate this class of bug when used correctly.
• Oracle manipulation — contracts that depend on on-chain price oracles (AMM spot prices) can be manipulated in the same transaction. Use TWAP oracles (Chainlink, Uniswap V3 TWAP) for any price-sensitive logic.

For any value-bearing contract: get a professional audit before mainnet deployment. Firms like Trail of Bits, Consensys Diligence, and OpenZeppelin Audits exist for this reason. The audit cost is a fraction of the cost of a successful exploit.

Where Blockchain Actually Adds Value (And Where It Doesn’t)

Blockchain adds genuine value when:

• Multiple parties with no pre-existing trust relationship need to transact
• A trusted centralized intermediary is expensive, slow, or a single point of failure you want to eliminate
• Auditability and immutability of transaction history are first-class regulatory or business requirements
• The workflow is well-defined enough to be codified as smart contract logic

Blockchain does NOT add value when:

• All participants trust a central authority (just use a database)
• The data is not inherently digital — a supply chain blockchain is only as trustworthy as the humans recording “product X entered warehouse Y” on-chain
• Transaction throughput requirements exceed what the chain can handle (Ethereum mainnet: ~15 TPS, though L2s change this significantly)
• The participants are internal to one organization (internal databases are faster, cheaper, and easier to operate)
• Privacy requirements conflict with the transparency the chain provides

The brutally honest summary: blockchain is the right solution for a narrow set of real problems. The failure mode of most enterprise blockchain projects is using blockchain technology for a use case that doesn’t actually need it — because the team heard “blockchain” and thought “distributed database,” which it is not.

Enterprise Blockchain in 2026: Where It Actually Landed

The hype cycle peak of 2017–2019 produced hundreds of enterprise blockchain pilot projects. Most did not make it to production. The ones that survived and scaled share a common characteristic: they solved a real multi-party trust problem, not a centralized data management problem.

The domains where blockchain has produced durable production deployments:

• Trade finance — letters of credit between banks across jurisdictions. Marco Polo, Contour (formerly Voltron) running on R3 Corda and Hyperledger.
• Securities settlement — post-trade settlement on blockchain (ASX CHESS replacement, DTCC Project Ion). The T+2 to near-real-time value proposition is real.
• Tokenization of real-world assets — the most active area in 2024–2026. BlackRock BUIDL fund, Franklin Templeton FOBXX, JPMorgan Onyx. RWA tokenization on public blockchains with institutional custody.
• Cross-border payments — Ripple (XRP Ledger), Stellar for remittance corridors. Not eliminating SWIFT but providing an alternative settlement layer.

---

Frequently Asked Questions

Is Ethereum still relevant for enterprise use in 2026?

Yes, but more through Ethereum L2s (Arbitrum, Optimism, Polygon) and EVM-compatible chains than mainnet. Enterprise deployments that need public blockchain properties (open participation, trustless settlement) but cannot tolerate mainnet gas costs and throughput limits are using L2 solutions. Mainnet is reserved for final settlement and bridge contracts.

What is Hyperledger Fabric and when should I use it?

Hyperledger Fabric is an open-source, permissioned blockchain framework under the Linux Foundation. It is designed for closed consortia where all participants are known and their membership is controlled. Use Fabric when you need blockchain’s audit trail and multi-party workflow properties but cannot use a public chain due to transaction privacy requirements, regulatory constraints, or the inability to hold cryptocurrency assets.

What is a smart contract audit and do I need one?

A smart contract audit is a professional security review of your Solidity (or Chaincode) code by specialist security engineers. They check for reentrancy vulnerabilities, access control mistakes, integer overflow/underflow, oracle manipulation vectors, and other smart-contract-specific attack patterns. If your contract controls real value (tokens, NFTs, ETH, or any asset with monetary value), you need a professional audit before mainnet deployment. No exceptions.

Why did most enterprise blockchain projects fail?

The most common failure: solving a problem that doesn’t require blockchain. Teams used blockchain as a distributed database, which it is not — it is a trustless settlement layer. A distributed database is much simpler, faster, and cheaper when the participants trust each other or trust a central authority. When blockchain’s specific properties (trustless settlement, censorship resistance, permissionless participation) are not required, blockchain is the wrong tool.

Is blockchain relevant for AI applications in 2026?

Increasingly yes, in specific ways: verifiable ML model provenance (recording model training data hashes and weights on-chain for auditability), decentralized compute marketplaces for ML training, and tokenized incentive systems for data labelling. The intersection of blockchain and AI is early but real. The same principle applies: these use cases genuinely benefit from trustless settlement and auditability — they are not blockchain for blockchain’s sake.

---

The Bottom Line

Blockchain is not going away, and it is not going to change everything. It occupies a specific and real niche: trustless settlement between parties who don’t trust each other and who want to eliminate a centralized intermediary. Within that niche, Ethereum (and its L2 ecosystem) and Hyperledger Fabric are mature technologies that have shipped real production systems at major financial institutions.

If you are evaluating blockchain for an enterprise use case: start by asking whether your use case actually requires trustless settlement. If all participants trust a central authority, use a database. If you genuinely need the trustless property — because participants don’t trust each other, or because you are eliminating a costly intermediary, or because immutable auditability is a regulatory requirement — then blockchain is worth the operational investment.

The engineers who build the best blockchain systems are the ones who understand both what the technology does well and what it doesn’t. The worst blockchain projects I have seen were built by teams who were excited about the technology before they understood the problem. The best ones were built by teams who had a specific trust problem and chose blockchain because it was the right tool, not because it was the fashionable one.

More from this blog:

• The Agentic SDLC: How Claude Code and Codex Are Rewriting the Developer Workflow
• Building Event-Driven Systems with Kafka: Lessons from 11 Years in the Field
• Distributed Systems Meets Machine Learning: Notes from Georgia Tech OMSCS