Blockchain for Enterprise: What Worked at Fidelity & RBS, and What the Agentic Era Changes

By Gaurav Pratap Singh  ·  March 2026  ·  14 min read
Blockchain Ethereum Enterprise Agentic SDLC Solidity

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. Most blockchain content is either breathless hype or breathless dismissal. This is a practitioner’s account of what actually worked, what failed, and what changed in the agentic SDLC era.

---

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: traditional securities transfer between custodians involved a T+2 or T+3 settlement cycle with manual reconciliation between multiple parties. The DApp replaced this with on-chain settlement using Solidity smart contracts, Web3.js, Truffle, and a Spring Boot backend. Settlement time dropped from 3 business days to near real-time. This project won Fidelity’s internal Shark Tank competition.

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. A smart contract enforces rules neutrally.
• Elimination of a trusted intermediary — 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, fulfilling a regulatory requirement naturally.
• All parties agreed on contract terms before deployment — this governance step is the one most blockchain projects skip and fail over.

What I would do differently with today’s tools:

• Smart contract upgradability from day one. We deployed immutable contracts and had to redeploy when requirements changed. The UUPS proxy pattern should be in the design from the start.
• Formal verification before mainnet. Certora Prover or Echidna fuzz testing didn’t make it into our stack. For value-bearing contracts, they’re mandatory.
• Gas cost modelling before deployment. We underestimated gas costs by 3x. Model this in advance.

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 — coaching 15+ engineers on Ethereum and Hyperledger Fabric. The hardest thing to teach: decentralized systems require a fundamentally different mental model. Enterprise engineers think in terms of a trusted central authority. Blockchain inverts this entirely.

What actually clicked for engineers:

• The vending machine analogy. A smart contract is a vending machine — put in the right inputs, get the guaranteed output, without trusting the owner.
• Live Hardhat demos on a local chain. Engineers who deployed a contract and saw events emitted in 10 minutes went from skeptical to engaged instantly.
• The trade finance proof-of-concept. Showing a working Spring Cloud + Ethereum system processing 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

The mistake I saw most often: enterprises choosing Ethereum for internal use cases where they controlled all participants. If you control who is in the network, you don’t need Ethereum’s permissionless design — you’re paying gas costs for something Fabric does better.

Smart Contracts Are Still a Footgun in 2026

The attack classes that have cost the most in production:

• Reentrancy attacks — update state before making external calls. The Checks-Effects-Interactions pattern is non-negotiable.
• Integer overflow/underflow — mitigated by native overflow checking in Solidity 0.8+, but upgrading pre-0.8 contracts remains a risk surface.
• Access control mistakes — functions that should be owner-only left public. Use OpenZeppelin’s Ownable and AccessControl.
• Oracle manipulation — use TWAP oracles (Chainlink) for any price-sensitive logic.

For any value-bearing contract: get a professional audit before mainnet deployment. The audit cost is a fraction of the cost of a successful exploit.

Where Blockchain Adds Value vs Where It Doesn’t

Genuine value: multiple parties with no pre-existing trust, eliminating a costly centralized intermediary, auditability as a first-class regulatory requirement, workflow codifiable as smart contract logic.

No value: all participants trust a central authority (use a database), data is not inherently digital, participants are internal to one organization, privacy requirements conflict with chain transparency.

---

Blockchain Development in the Agentic SDLC Era: Before and After

The strategic questions — whether to use blockchain at all, which platform, how to govern the consortium — haven’t changed. The development workflow has.

Before (Pre-2024): What Blockchain Development Actually Took

Setting up a new Ethereum DApp development environment and writing your first Solidity contract meant navigating a fragmented ecosystem by hand. Smart contract development was particularly painful because of two properties: the language was new (Solidity 0.4–0.6 era had sharp edges), and the feedback loop was slow (compile, deploy to local Ganache, call function, check output, repeat).

After (Agentic SDLC): Scaffold in 10 Minutes, Audit Still Takes Weeks

Here are the prompts I use today for blockchain work:

# Solidity contract scaffold
Generate a Solidity 0.8 smart contract for a two-party asset settlement workflow:
- Parties: initiator and counterparty (both must be whitelisted addresses)
- States: PENDING, ACCEPTED, SETTLED, CANCELLED
- Functions: initiateTransfer(), acceptTransfer(), settleTransfer(), cancelTransfer()
- Use OpenZeppelin Ownable for admin, AccessControl for party whitelist
- Emit events for every state transition with timestamp
- Include UUPS upgradeable proxy pattern
- Add NatSpec documentation on every function

# Hardhat test suite
Generate Hardhat tests for the above contract:
- Happy path: full PENDING → ACCEPTED → SETTLED flow
- Access control: non-whitelisted address attempting each function
- Reentrancy check: mock a malicious contract attempting reentrancy on settleTransfer()
- State machine: calling acceptTransfer() on a CANCELLED settlement (should revert)
- Event emission: verify all events fire with correct args

# Vulnerability pre-check (NOT a replacement for audit)
Review this Solidity contract for the OWASP Smart Contract Top 10:
- Reentrancy
- Integer overflow/underflow
- Access control mistakes
- Timestamp dependence
- Front-running exposure
For each finding: severity, line reference, and recommended fix.

Claude Code generates the contract, tests, and vulnerability pre-check in under 10 minutes. The output is a solid starting point that follows Solidity best practices.

The Before/After Comparison: Smart Contract Development

The One Thing AI Cannot Change About Smart Contract Security

The fundamental property of smart contracts — that bugs cannot be rolled back after deployment on a public chain — means the stakes of insufficient security review are categorically higher than in traditional software. A misconfigured Spring Boot service can be patched in a rolling deployment. An exploited reentrancy vulnerability on mainnet results in irreversible loss of funds.

AI-assisted vulnerability pre-check is genuinely useful for catching obvious mistakes before they reach a professional auditor. It reduces the scope of issues the auditor needs to investigate, which can reduce audit cost. It is not a substitute for the auditor. The adversarial creativity of professional exploit researchers — who model attack vectors across the full contract interaction space, including flash loan attack surfaces and cross-contract reentrancy — is not replicated by current AI tools.

Use AI for scaffolding, testing, and first-pass vulnerability checking. Use professional auditors for any contract that will hold real value.

---

Enterprise Blockchain in 2026: Where It Actually Landed

The hype cycle peak of 2017–2019 produced hundreds of enterprise blockchain pilots. Most didn’t reach production. The ones that survived solved a real multi-party trust problem. The domains with durable deployments: trade finance (Marco Polo, Contour on Corda/Hyperledger), securities settlement (DTCC Project Ion), tokenization of real-world assets (BlackRock BUIDL, JPMorgan Onyx), cross-border payments (Ripple, Stellar).

---

Frequently Asked Questions

Is Ethereum still relevant for enterprise use in 2026?

Yes, primarily through L2s (Arbitrum, Optimism, Polygon) and EVM-compatible chains. Enterprise deployments that need public blockchain properties but can’t tolerate mainnet gas costs use L2 solutions. Mainnet is reserved for final settlement and bridge contracts.

Can AI generate secure smart contracts?

AI can generate Solidity contracts that follow best practices and are free of the most common vulnerability patterns when given a precise spec. It can also perform a first-pass vulnerability review. What it cannot do is reason about novel attack vectors, flash loan attack surfaces, or the full cross-contract interaction space. For contracts that hold real value, a professional audit by firms like Trail of Bits or OpenZeppelin is non-negotiable regardless of AI pre-review.

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. If participants trust a central authority, use a database. Blockchain’s value — trustless settlement, censorship resistance, permissionless participation — is only relevant when the use case genuinely needs those properties.

Is blockchain relevant for AI applications in 2026?

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

---

The Bottom Line

Blockchain occupies a specific and real niche: trustless settlement between parties who don’t trust each other and want to eliminate a centralized intermediary. The agentic SDLC reduced the development cost of smart contracts significantly — scaffolding, testing, and first-pass security review that took 3+ hours now takes under 15 minutes.

What didn’t change: the strategic question of whether blockchain is the right tool (most of the time, it isn’t), and the security imperative for professional audit of any value-bearing contract. The AI saved the ceremony. It cannot change the immutability of a deployed contract or the ingenuity of an adversarial exploit researcher.

More from this blog:

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

---

Gaurav Pratap Singh is a Principal / Staff Software Engineer at UKG with 11 years in distributed systems and enterprise Java. He is pursuing an MS in CS at Georgia Tech (OMSCS — Computing Systems + ML).