Hello and welcome. Today we’re cutting through the haze around smart contracts so you can actually use them to design a product, assess risk, or argue a case inside a U.S. business. This is the practical version I teach to engineers and executives. Two truths to clear the fog: 1) A smart contract is software—code plus data—running deterministically on a blockchain. 2) The power is in the network guarantees: consistent execution worldwide, verifiable by anyone, and not unilaterally changeable once live unless you designed a mechanism for it. On Ethereum, a contract lives at a unique address and runs in the Ethereum Virtual Machine, a sandbox that makes every node execute the same way. You call a function with a transaction; every node runs the code; if rules pass, state updates. Think vending machine: right inputs, same output. And there’s no “undo.” That immutability is the superpower and the risk. Why use smart contracts? - Trust minimization: no single operator or intermediary. Code enforces the rules. - Composability: contracts call other contracts like Lego bricks; complex DeFi actions can happen atomically. - Programmable assets: tokens (ERC-20, NFTs) are contracts with standard interfaces, so apps interoperate. - Global reach: 24/7 access if you can reach the network. - Transparency: permanent, public audit trail. Powerful for compliance, but it cuts both ways. You pay for these benefits: transaction fees (gas), latency to finality, and new security/compliance duties. For many U.S. enterprise cases, go hybrid: keep UX off-chain, settle critical bits on-chain. Prototype core logic on a testnet before you commit. One layer deeper. There are two account types: - Externally owned accounts (EOAs): users controlled by private keys. - Contract accounts: code plus storage. Only EOAs initiate transactions and pay gas. Contracts can’t wake themselves up; they react to calls. A transaction includes the target, function and inputs, gas limit, and fee. Validators execute. If it runs out of gas or fails a check, it reverts with no state change. If it succeeds, updates are atomic. That determinism lets the network agree on a single state without trusting any one computer. Mental model: treat smart contracts like shared infrastructure—stable, public APIs anyone can integrate with. Unlike normal APIs, you can’t secretly change behavior later. If you need upgrades, design and disclose the path up front. Three early decisions make or break projects: Decision one: governance and upgradeability. Immutable or upgradeable proxy? - If upgradeable, who can upgrade, through what process, and with what delay? - Best practice: multisig control, a timelock so changes are visible in advance, and clear limits on what upgrades can do. - If you need emergency powers , state exactly what and when. Hide nothing. Ship nothing you can’t fix unless that’s intentional. Decision two: access control and key management. - Who can move funds? Set parameters? Which roles exist ? - How are keys secured—hardware, custody, rotation? - What’s the recovery plan for lost keys? - Add spending limits, rate limits, circuit breakers for sensitive ops. - In the U.S., assume a regulator will ask, “Who can press which buttons?” Be ready to answer plainly. Decision three: external dependencies and failure modes. - Do you rely on price oracles, randomness, or other protocols? - Sandbox external calls so failures or manipulation don’t cascade. - Use pull over push payments; update internal state before external calls; cap loops to avoid gas griefing; set safe defaults for stale or paused dependencies. - Choose chain and scaling early. L1 vs L2 affects fees, finality, and UX. Document why and how you’ll handle migrations. Get these boundaries right and you avoid most headline exploits. Common missteps: - Shipping without a threat model or invariant tests. Invariants are “must never break” rules like total supply equals sum of balances, or collateral exceeds debt. - Hiding admin powers in code comments instead of plain-English docs. - Unbounded loops that let users blow up gas. - External calls before internal state updates (reentrancy). - Ignoring UX around approvals and gas, which leads to phishing and stuck transactions. What does a transaction feel like? - A user signs with their wallet, sets gas limit and fee. - Validators pick it up, run the code, and on success, state updates and events emit. - Events are your off-chain analytics and app signals. - Finality varies: on Ethereum mainnet you wait several confirmations; some L2s are faster locally but settle to mainnet later. This affects latency, refunds, and support flows. Legal and compliance for a U.S. audience: - Sanctions compliance and screening, especially with stablecoins or public interfaces that could serve sanctioned jurisdictions. - Securities/commodities questions for some tokens and yields. - Money transmission licensing if you custody or move assets for users. - Records retention and audit readiness—on-chain logs help, but you still need to map addresses to entities. - Privacy—on-chain is public; avoid linking personal data to addresses in ways you can’t undo. Aim to minimize custody and discretionary control, and document any controls you retain. Before mainnet, answer these out loud: - What’s the single-sentence promise of your contract? - What are your invariants? - What fails safe if a dependency breaks or is manipulated? - Who can upgrade, pause, or drain funds, under what process, and how is that disclosed? - What’s your key management and rotation plan? - Which chain and why? - What’s your incident response plan, including public comms and safe halts? - How will you test—unit, property, fuzzing, testnet dry runs—and who audits? - Do you have a bug bounty and disclosure policy? - What must be on-chain, and what stays off-chain for speed and cost? A quick example: a U.S. loyalty program. - Deploy an ERC-20-style points token. Minting is controlled by a multisig with daily caps. - A redemption contract burns points for rewards. - Keep catalog and supply chain off-chain; settle redemptions on-chain. - Use an upgradeable setup with a timelock; document the upgrade scope. - Onboard with a custodial wallet for mainstream users, but allow self-custody for advanced users. - Publish plain-English docs: who can mint, how upgrades and pauses work, incident playbook. This gets you interoperability and auditability without forcing everything on-chain. How to start: 1) Sketch your invariants. 2) Build a minimal testnet contract capturing core logic. 3) Add a simple front end and watch real gas, latency, and UX friction. 4) Trim anything that doesn’t need to be on-chain. 5) Lock in governance, key management, and dependency boundaries. 6) Test hard, get an external audit, then run a bug bounty. Only then consider mainnet. The simplest way to think about it: smart contracts are ultra-honest robots. They do exactly what you tell them, every time, in public. With clear rules, tight scope, and transparent governance, you build infrastructure others can depend on. Treat it like a normal app you’ll “fix later,” and you’re setting yourself up for pain. Thanks for listening. If this clarified whether smart contracts fit your problem, ship a testnet prototype this week. You’ll quickly learn if the guarantees are worth the tradeoffs for your use case.