Why Smart Contracts Caught My Attention - Blockchain x AI Agents
Posted: 14 May, 2026 · ~14 min read
A PM's first-principles pathway into blockchain.
I've spent the last two years going deep on agentic AI. So what pulled me toward smart contracts?
The short answer: I'm an Technical PM, and AI products are about to need a trust layer that doesn't exist in Web2. The longer answer is what this post is about - but it's not really an AI post. It's an honest field report on what it looks like to onboard to blockchain as a PM in 2026: what to learn, in what order, on which tools, and what to skip.
If you're a PM who has been curious about blockchain but never found a non-cringe way in, this is the post I wish I'd had six months ago.
This is the field report. Settle in.
First principles: what does blockchain actually solve?
Most blockchain explanations start with "imagine a distributed ledger." That framing is technically correct and intuitively useless. Here's the framing that worked for me:
Blockchain is a database with a single weird property: nobody owns it, but everyone agrees on its state.
Every other database in the world has a privileged actor - the server admin, the DBA, the company that hosts it - who can change history. Blockchain replaces that privileged actor with a consensus mechanism. The tradeoff is brutal: you give up speed, storage cost, flexibility. What you get is programmable trust.
That's the whole magic. Everything else is implementation detail.
Once you accept that as the core feature, a lot of follow-on questions answer themselves. Why is gas expensive? Because consensus is expensive. Why are smart contracts immutable by default? Because the whole point is removing privileged actors who can change them later. Why does decentralized finance look so weird compared to a Stripe dashboard? Because every interaction is a public, replayable, signed message - there's no backend hiding the mess.
The PM question becomes: is the cost of programmable trust worth it for this product? For 90% of consumer apps, no. For agent infrastructure, payments between mutually-distrustful parties, audit trails that need to survive their issuer, or financial products that can't have a single point of control - yes.
The mental model: seven primitives every PM should know
You don't need to write Solidity to PM blockchain products. You need a working mental model of seven primitives. Here's mine, with the PM lens for each.
PM lens: every flow either makes the user manage a key or abstracts it away (custody, social recovery, passkey-based smart accounts). No third option. The choice you make here shapes everything else about your UX.
PM lens: every user action has a cost, a latency, and a failure mode you cannot fully hide. Build your UX around the assumption that some percentage of transactions will fail mid-flight. The status page for your product is the chain.
PM lens: ship the contract wrong, ship a public bug that everyone can exploit forever. There is no hotfix. Auditing is not optional. The mindset shift from "iterate fast and patch" to "ship deliberately and rarely" is the single biggest cultural change for Web2 PMs entering this space.
PM lens: tokens are standardized state - they let you compose ownership across protocols you don't control. Your contract doesn't need to know about Uniswap; Uniswap knows about your ERC-20 because it follows the standard. This is the closest thing crypto has to a USB-C moment.
PM lens: oracles are where most "blockchain solves X" pitches quietly fall apart. You don't escape trust; you concentrate it in the oracle. Chainlink, Pyth, RedStone are the major ones. Their failure modes are interesting reading and inform what's actually buildable.
PM lens: gas is your latency × cost knob. It's why Layer 2s (Base, Arbitrum, Optimism) exist - to make execution cheap enough for products with frequent small transactions. Pick your chain by mapping your transaction frequency and value distribution against gas economics. A high-frequency app on mainnet Ethereum is a non-starter.
PM lens: you usually don't pick a consensus mechanism, you pick a chain - and the chain bundles consensus + ecosystem + tooling + community. Pick the chain that matches your product's profile, not the one your friends like.
If you can fluently explain those seven to a non-technical PM in 30 seconds each, you have enough mental model to start having useful conversations with engineers. Everything else is depth.
Learning path
When I started a week ago, I tried four resources in parallel: a CryptoZombies tutorial, a Solidity by Example walkthrough, the OpenZeppelin docs, and Cyfrin Updraft. Three I abandoned. Cyfrin is the one I finished and still go back to.
Why Cyfrin won: it's built around production craft, not pedagogy. Patrick Collins (the co-founder) was the lead Solidity educator on FreeCodeCamp for years. Updraft is what he wishes he could have made there - graded exercises, real projects, audit-style writeups. The security course in particular is brilliant: it teaches you how contracts get hacked, which is the only way to learn to write them correctly. You watch real exploits replayed, read post-mortems of $100M+ hacks, and write your own exploits as homework.
Here's the week-by-week pathway I'd recommend:
I cut above to most important topics and went through them within a week (still need to finish the learnings)
The toolchain choice: Hardhat vs Foundry
This is the section that took me longest to figure out because the internet's advice is contradictory and tribal. Here's the honest comparison after building with each.
Hardhat's strengths are real:
- TypeScript familiarity for teams coming from Web2
- The plugin ecosystem is broader and more mature
console.loginside Solidity is genuinely the best debugging experience in the entire ecosystem- Hardhat Ignition makes multi-contract deployments declarative in a way Foundry scripts don't match
I built a simple use cases in Hardhat first, on purpose - a basic ERC-20 with vesting. Toy version.
Three reasons I chose Hardhat as the starting point:
- Familiarity reduces friction. TypeScript is language I'm shifting towards. Starting in TS meant I could focus on Solidity semantics without also fighting unfamiliar Rust-flavored tooling. Lower friction = more iterations = more learning per hour.
- Ecosystem depth. Every "how do I do X" question I hit during the toy projects had a Hardhat tutorial. Foundry's docs are excellent but the long tail of community tutorials is smaller. For a beginner, the long tail matters more than the official docs.
- Personal curiosity.
The point of building a toy wasn't the products. It was internalizing the dev loop end-to-end: write contract → compile → test → deploy → verify on Etherscan → call from a frontend. Twenty hours of doing that for real teaches you more than two hundred hours of reading about it. There's something about seeing your own contract on a public block explorer that locks the mental model in place.
My recommendation by background:
- TypeScript-comfortable or frontend-curious: start with Hardhat, add Foundry by week 10.
- Protocol-focused or security-curious: start with Foundry.
- Don't know which: start with Hardhat. It's friendlier and the on-ramp is gentler.
What to learn and what to skip
There's a lot of noise in this space. Here's the filter I wish I'd had on day one.
Three resources beyond Cyfrin worth your time:
- Solodit - Cyfrin's aggregator of security findings across major audit firms. Reading 20 audit reports gives you more pattern recognition than 200 hours of generic tutorials. Sort by severity, read the High and Critical findings first, look for the recurring patterns.
- Token Terminal and DeFiLlama - Real protocol revenue, real TVL, real user counts. The numbers will quickly recalibrate your sense of what's actually working from what's loud on Twitter. Use both - they disagree in informative ways.
- Ethereum.org developer docs - Surprisingly good once you have the basics. Reference, not starting point. The "advanced" sections on account abstraction and the Pectra/Fusaka upgrades are particularly worth understanding for PMs thinking about agent infrastructure.
Where this gets interesting: blockchain × agentic AI
I said this wasn't an AI post, and the body hasn't been. But I'd cheat you if I closed without saying what's actually pulling me toward blockchain - because it's not the technology in isolation. It's the seam.
I love merging technologies. The most interesting product opportunities live where the constraints of one stack are dissolved by the affordances of another. With AI and blockchain, the seam is fertile in a way nobody is articulating well yet.
The pattern: AI agents need infrastructure built for non-human actors, and blockchain (in my opinion) is the only infrastructure that natively serves non-humans.
Today's APIs assume a human user behind every request. Today's payment rails assume a human cardholder. Today's identity systems assume a human face for KYC. Agentic AI breaks all of those assumptions, sometimes catastrophically. Blockchain is what you'd design from scratch if your starting point was "the user might be a script."
Four use cases I'm watching and partly building toward:
None of this requires new science. All of it requires infrastructure that exists in 2026 but is being assembled by tiny teams with little PM presence.
This is what I mean by merging technologies. Solidity on its own is interesting if you're a protocol engineer. Agentic AI on its own is interesting if you're an applied AI PM. But the cross-product - agents that can hold, commit, prove, and earn on-chain - is a 10× larger surface than either stack alone. And almost nobody is positioned to PM it well, because almost nobody is fluent in both.
That's the bet.
Closing: what to do this week
If you've read this far, you're at least curious. Three actions, ordered by effort:
- Spend 90 minutes on Cyfrin Updraft's Blockchain Basics. Free, low commitment. Sets the mental model.
- Open a MetaMask wallet, fund it with $20 of ETH on a Layer 2 (Base or Arbitrum), and complete one real transaction. Buy a stablecoin. Send it to yourself.
- Pick one toolchain and ship a toy contract. Hardhat if you're TS-comfortable, Foundry if you're security-curious. Deploy a tiny ERC-20 to Sepolia testnet. Verify it on Etherscan. Take a screenshot.
If you do those three things, you'll know in a weekend whether blockchain belongs in your career bet.
For me, the answer was yes - not because I'm leaving AI, but because the next generation of AI products will live on-chain whether their builders intend it or not.
Tagged: #Blockchain #Solidity #Cyfrin #Hardhat #Foundry #ProductManagement #AgenticAI #PMCareer #Web3 #SmartContracts