DEV Community: Joshua Ofamba

I Built a Website Without Paying for Hosting—Here’s What Happened

Joshua Ofamba — Wed, 01 Apr 2026 12:31:56 +0000

Most people assume a website requires a hosting bill. That assumption is wrong. IPFS lets you publish a real, custom-domain website on a peer-to-peer network — for free.

Photo by NASA on Unsplash

If you have ever built a personal site, portfolio, or small project, you know the drill: pick a host, enter a card number, wait for the bill. It feels like the cost of doing business. It isn’t.

The InterPlanetary File System (IPFS) is a peer-to-peer protocol that lets you publish static websites without leasing space on anyone’s server. This article walks you through building a site, publishing it to IPFS, and pointing a real domain at it — no hosting contract required.

Let’s see how we can achieve this:

How IPFS Works for Websites

Traditional hosting points a URL at a specific server. If that server goes down, your page goes with it. IPFS flips this centralized model to a peer-to-peer(P2P) model.

When you add a file to the IPFS network, it receives a Content Identifier (CID). This is a cryptographic hash derived from the file’s contents. Any node(peer) holding your file can serve it, so there is no single point of failure and no single bill to pay.

The trade-off is that IPFS only works with static sites — HTML, CSS, JavaScript, and assets like images or videos. Dynamic server-side languages like PHP or Python are not supported. For server-side functionality, you still need traditional infrastructure. If your project only runs on the frontend, then you’re good to work with IPFS.

Build Your Site

First, let’s set up a local IPFS node. You can follow this article on how to download and install one.

IPFS doesn’t care how you author your content. You can write plain HTML, use a static generator like Hugo or Eleventy, or even scaffold a React app.

Here is a minimal HTML file to get you started:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>My IPFS Site</title>
  <link rel="stylesheet" href="./style.css" />
</head>
<body>
  <h1>Hello from IPFS</h1>
</body>
</html>

Copy the content above and place it in a file named index.html. Now, open your IPFS node and navigate to the Files page. Next, click the Import button, choose the File option, and upload the index.html file created earlier.

After the upload, click on the three dots on the file and choose Share link.

That’s it. You should have a link that resembles this:

https://bafybeifkygjhioi37knmgvlpl5lnbxo6lphn76raedrvsskihcn4sfwguq.ipfs.dweb.link?filename=index.html

You can paste this link into the browser to view your deployed site. For the first time, it may take about a minute for it to load. You should then see a page like this:

The Redeployment Problem

Every time you change a file and re-import it, IPFS generates a brand-new CID. Anyone who bookmarked or linked to your old CID now hits a dead end. For a site you plan to update, this is a real problem.

IPFS solves this using IPNS (InterPlanetary Name System), which is a mutable naming system that always points to your latest CID. Think of it as a forwarding address: you publish once to an IPNS key, and it redirects to whatever CID you tell it to.

The IPFS documentation on IPNS explains more about how to generate and publish IPNS keys.

Keep Your Site Online: Three Approaches

Importing a folder into IPFS Desktop makes your content available from your machine. But when your laptop closes, so does your site. You have three options for keeping it live.

1. Self-Hosting

Self-hosting means running your own IPFS node continuously to keep your content available on the network. If you have a home server or a VPS, you can keep an IPFS node running there and pin your CID. Pinning means that your IPFS node permanently stores the imported data. By default, IPFS treats your uploads as temporary, so you have to make them permanent by pinning.

For production use, self-hosting may not be practical due to challenges associated with managing your infrastructure, e.g., during a downtime.

2. Pinning Service

Pinning services handle persistence for you by storing and serving your IPFS content on always-on infrastructure. After uploading your site, the service pins your CID.

Popular providers like Pinata and Filebase provide 1GB of free storage to try out their services. They typically offer APIs, dashboards, and SDKs for managing uploads and pins. This is the most common approach for developers who want reliability without maintaining infrastructure.

The trade-off is partial dependence on third-party services, though your data remains content-addressed and accessible across the IPFS network.

3. Automated Deployment via GitHub Actions

This approach integrates IPFS deployment into your CI/CD pipeline. Whenever you push changes to your repository, a workflow automatically builds your site and uploads it to IPFS using a pinning provider.

Using GitHub Actions, you can define workflows that trigger on commits, generate a new CID, and optionally update DNS records (e.g., via IPNS or DNSLink). This ensures your IPFS-hosted site stays in sync with your codebase without manual intervention.

Set up a Custom Domain

Sharing a raw gateway URL works, but ipfs.io/ipfs/Qm… is not something visitors will remember or trust. You can instead link your IPFS URL to standard domain names like example.com.

You can login to your domain registrar’s dashboard, find the domain’s redirect (or forwarding) settings, and point it to your IPFS gateway URL. After this, your users will now be able to access the site using the domain name.

Conclusion

IPFS proves that hosting isn’t a requirement; it’s a choice. You can publish a real, custom-domain website with no hosting bill.

There are still some trade-offs, but the technology is improving. The decentralized web is the future.

the FFmpeg example really hit home. i personally didn't know that the ffmpeg team writes assembly code by hand to give us as much as x50 speed up compared to a high-level approach!!

Joshua Ofamba — Mon, 30 Mar 2026 08:40:12 +0000

Joshua Ofamba

Mar 30

I Tried Contributing to Open Source—And Now I Understand Why People Do It for Free

#opensource

Comments

7 min read

I Tried Contributing to Open Source—And Now I Understand Why People Do It for Free

Joshua Ofamba — Thu, 26 Mar 2026 09:05:26 +0000

Photo by Luke Chesser on Unsplash.

Most of the software I use every day is free. Not “free trial” free, but fully open, maintained by people who aren’t getting paid for it. For a long time, that didn’t make sense to me. Why would skilled developers spend hours writing, reviewing, and maintaining code for strangers on the internet?

So I decided to find out for myself.

I picked a project (OWASP), set up my environment, and attempted my first contribution. I expected it to be complicated, maybe even frustrating. And it was. But what surprised me wasn’t just the process—it was what I learned about why people keep showing up and contributing, even when there’s no paycheck involved.

Below, I'll share with you the things I learned from following open-source projects on social media, joining their communities, and ultimately making my first contribution.

1. Your Work Gets Recognized, Permanently

One of the most underrated perks of open-source contribution is recognition that goes far deeper than a LinkedIn endorsement. When you contribute to a public repository, that work is attributed to you on platforms where employers and collaborators are actively looking.

GitHub stars are one of the simplest and most visible signals of real-world impact. If a project you’ve built or contributed to has hundreds of stars, it shows that people are actually finding it useful—something a personal portfolio alone can’t easily demonstrate.

On top of that, tools like GitPOAP⁠ take recognition a step further by turning your merged pull requests into verifiable, shareable records tied directly to your GitHub identity. These show up as digital badges linked to specific contributions or events, making it easier to demonstrate not just what you’ve worked on, but where and how you’ve participated.

The GitHub Arctic Code Vault stores a snapshot of the most used public repositories on an archival film beneath the ice-cold rocks in Svalbard, Norway.

The most dramatic example of open source recognition, however, is the GitHub Arctic Code Vault. On February 2, 2020, GitHub captured a snapshot of every active public repository and encoded it onto archival film designed to last 1,000 years, then stored it beneath a mountain in Svalbard, Norway. If you contributed to any qualifying project before that date, your name is literally preserved in permafrost. GitHub marks this on contributor profiles with the Arctic Code Vault badge, visible to anyone who views your profile.

Contributing to open source doesn’t just build a resume. It builds a verifiable, public, and in some cases permanent record of who you are as a developer.

2. It Can Be a Hard Career Requirement

I used to think open-source was something you did after you got good. In reality, it’s often how you prove you’re good in the first place.

When I started exploring opportunities, especially in web3, I kept running into the same pattern: people who were getting internships, grants, or early roles almost always had some form of open-source contribution. Not massive projects. Just evidence that they had worked in public.

For instance:

Some internship programs (like those under OWASP) explicitly prioritize applicants who have made public contributions before
In many web3 communities like Ethereum, grants are normally given out to applicants that have open-source contributions in the ecosystem

And when I made my first few contributions, I realized that employers weren't asking for perfection. All they needed was proof that you can integrate into their current development workflow.

So while open source might look like “free work” on the surface, in practice it’s closer to:

a public portfolio
a collaborative interview
and, in many cases, a gateway into opportunities

Even if you’re not targeting open-source-heavy roles, the habits you build while contributing are valuable. They include navigating large codebases, writing clear commit messages, and working asynchronously across time zones. These are professional skills most bootcamps and universities do not teach.

3. The Projects You Use Need You More Than You Think

There’s a tension at the heart of open source that most users never see. A handful of unpaid volunteers often maintains the tools that power trillion-dollar products. And when those volunteers get overwhelmed, entire categories of software become fragile.

The FFmpeg situation in mid 2025 illustrated this perfectly. FFmpeg is a multimedia framework that powers Google Chrome, YouTube, Firefox, VLC, and countless other products. It’s the silent backbone of internet video, maintained by just a handful of passionate developers. When Google’s AI security tool, Big Sleep, began filing vulnerability reports to the project without providing patches, FFmpeg maintainers fired back, arguing that Google’s AI tools were dumping reports without solutions on projects largely sustained by unpaid volunteers.

// Detect dark theme var iframe = document.getElementById('tweet-1950227075576823817-661'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1950227075576823817&theme=dark" }

The community’s frustration was pointed and accurate: many in the FFmpeg community argue, with reason, that it is unreasonable for a trillion-dollar corporation like Google, which heavily relies on FFmpeg in its products, to shift the workload of fixing vulnerabilities to unpaid volunteers. You may not be a trillion-dollar corporation. But if you use a library every day and never contribute a bug fix, a documentation improvement, or a test case, you’re participating in the same dynamic on a smaller scale.

Since the earlier shown post on X, many companies like Spotify and Elevenlabs have contributed thousands of dollars to the project. You too can donate to the open-source projects you use by visiting their Sponsor page on GitHub.

4. You Get Free Mentorship From Senior Engineers

Open source is one of the few places where you can get your code reviewed by world-class engineers, for free, on real production software. That feedback loop is extraordinarily valuable, especially early in your career.

When you open a pull request, you’re submitting your work for scrutiny by people who have often spent years or decades on a codebase. They’ll tell you what you got wrong, how to fix it, and why the idiomatic approach matters. A review comment like “this causes an O(n²) lookup — consider a hash map here” teaches you something no tutorial video replicates, because it’s attached to code you wrote with real stakes.

Here’s what a simple but well-structured first contribution might look like:

# 1. Fork the repo on GitHub, then clone your fork locally
git clone https://github.com/your-username/some-project.git
cd some-project

# 2. Create a new branch — never work directly on main
git checkout -b fix/steps-in-readme

# 3. Make your edit, stage it, and write a clear commit message
git add README.md
git commit -m "fix: added missing steps in installation instructions"

# 4. Push your branch to your fork and open a pull request on GitHub
git push origin fix/steps-in-readme

This process, repeated across increasingly complex contributions, is how junior developers become mid-level ones. You’re practicing on real software, getting feedback from engineers who care about quality, and shipping real improvements. It’s structured learning with actual consequences — which is exactly what makes it stick.

5. You’ll Build a Network That Opens Doors

Open source communities are some of the most accessible professional networks in software development. You don’t need a warm introduction, a university connection, or a conference ticket. You just need to show up, be helpful, and be consistent.

Most major open source projects maintain active Discord or Matrix communities where contributors discuss everything from bug fixes to career opportunities.

Most active open source projects maintain a presence on platforms like Discord or Matrix, where contributors discuss bugs, debate design decisions, and share opportunities. These communities are global, and the people in them are often hiring, advising, or sitting on grant committees.

Contributing consistently puts you in direct contact with people who can change your career trajectory. You might receive an invitation to a paid open-source fellowship.

Programs like Outreachy or Google Summer of Code pay developers to contribute to open source full-time for a summer. You might get noticed by a maintainer who later becomes a professional reference or a startup co-founder. You might simply get a perspective-shifting conversation with a developer who solves problems very differently from anyone in your immediate circle.

This isn't hypothetical. Rich Harris, creator of the popular open-source JavaScript framework called Svelte, was hired by Vercel to work on it full-time.

The network effect of open source is slow and compounding. The developers who’ve been contributing consistently for two or three years have not just been building a stronger portfolio but also trust. In software, that trust is the hardest thing to build from scratch.

Where to Start

If you’ve never contributed before, the barrier feels higher than it actually is. You don’t need to fix a critical security vulnerability on your first pull request. Documentation improvements, test coverage additions, and bug reproductions are all legitimate, welcomed contributions. Most projects mark beginner-friendly tasks with labels like good first issue or help wanted, so you can filter to tasks that match your current skill level.

The best starting point is the tools you already use every day. If you find yourself wishing a library had better error messages, check whether there’s an open issue. If the documentation confused you the first time, you already know what’s missing. Your experience as a user is valuable context that maintainers don’t always have. Over time, these small contributions compound into real-world engineering experience that is hard to replicate in isolated practice.

7 Web3 Security Mistakes Even Experienced Users Are Still Making

Joshua Ofamba — Wed, 25 Mar 2026 14:43:03 +0000

You know not to share your seed phrase. You use a hardware wallet. You’ve read the horror stories. And yet the most costly attacks in DeFi keep hitting people who thought they’d covered the basics. Here’s what you’re probably still getting wrong.

Today’s exploits happen in the gap between what you think you’re approving and what actually executes. From compromised frontends to hidden permissions in ‘gasless’ signatures, the goal is to make a malicious transaction look like normal ones. If an attacker can gain your authorization, they don’t need your password.

What follows are seven mistakes that consistently turn up in post-mortems, across wallets of every size. Some are operational habits. Some are knowledge gaps. All of them are fixable today.

1. You’re Using a Single Wallet for Everything

A single address accumulating six months of on-chain activity is a dossier. Every protocol you’ve interacted with, every approval you’ve granted, every NFT mint you’ve participated in is permanently visible. This is not inherently dangerous, but combining your main holding wallet with your active trading wallet, your test wallet, and your airdrop-farming wallet turns a manageable risk surface into an enormous one.

The more consequential problem is address poisoning. An attacker monitors your transaction history, then generates a vanity address that shares the first four and last six characters of a wallet you regularly send to. They send you a zero-value transfer from that address. You later copy-paste from your transaction history rather than your address book, and funds go to an address you’ve never controlled. This attack is low-effort, has no on-chain prevention mechanism, and works precisely because experienced users move fast and rely on visual shortcuts.

Real-world impact

Address poisoning attacks have been responsible for multi-million dollar losses in 2023 and 2024, including a well-documented case where a trader lost $68M in WBTC by copying a poisoned address from their own transaction history. Speed is the attacker’s ally here.

The fix

Maintain at least three distinct address buckets:

Cold vault (hardware wallet): used strictly for long-term storage and never interacts with smart contracts.
Trading wallet (hot wallet): handles routine DeFi activity and serves as the operational wallet.
Dev / experimental wallet : isolated environment for unaudited protocols, new deployments, or testnet spillover.

Funds should never move directly between the cold vault and the experimental wallet. Instead, route transfers through the trading wallet to introduce a deliberate, manual checkpoint.

While verifying full addresses character-by-character is often impractical, you can reduce risk by using tools like MetaMask’s address book rather than copy-pasting from history.

2. You’ve Never Audited Your Token Approvals

Unlimited token approvals accumulate silently. Most wallets don’t show them proactively.

When you approve a protocol to spend your tokens, that approval persists indefinitely unless you revoke it. Every decentralized application (dApp) interaction you’ve completed over the past two years has likely left at least one open approval. Some of those protocols have since been compromised, abandoned, or had their contracts upgraded by a multisig you have no visibility into.

The attack vector is straightforward: a protocol you approved 18 months ago gets exploited. The attacker drains every wallet with an outstanding approval, not just current users. You haven’t touched that protocol in over a year, but your approval is still live. This is not a theoretical risk; it has driven the majority of DeFi drain events on record.

Here’s JavaScript code using ethers.js to help you check outstanding approvals:

const { ethers } = require("ethers");

// Minimal ERC-20 ABI — allowance function only
const ERC20_ABI = [
  "function allowance(address owner, address spender) view returns (uint256)"
];

async function checkApproval(tokenAddress, ownerAddress, spenderAddress, provider) {
  const contract = new ethers.Contract(tokenAddress, ERC20_ABI, provider);
  const allowance = await contract.allowance(ownerAddress, spenderAddress);

  if (allowance.eq(ethers.constants.MaxUint256)) {
    console.warn(`⚠ Unlimited approval active for spender: ${spenderAddress}`);
  } else if (allowance.gt(0)) {
    console.log(`Allowance: ${ethers.utils.formatUnits(allowance, 18)} tokens`);
  } else {
    console.log("No approval outstanding.");
  }
}

The fix

Run a full approval audit using Revoke.cash across every chain you’ve been active on. Revoke anything you don’t actively use today. Going forward, prefer protocols that use exact-amount approvals over unlimited ones, and consider using a wallet interface that surfaces active approvals in-session, like Rabby.

3. You’re Broadcasting Transactions Without MEV Protection

MEV (Maximal Extractable Value) is not an abstract protocol-level concern. It hits you directly every time you execute a swap on a public mempool without protection. The most common form you’ll encounter is the sandwich attack: a bot detects your pending transaction, front-runs it to push the price, lets your trade execute at the inflated price, then back-runs to pocket the difference. Your slippage tolerance is not a defence — it’s the parameter the bot calibrates against.

On a large swap, the extracted value is often invisible to you because it sits inside your slippage allowance. On smaller trades, you simply receive fewer tokens than you should. It is a persistent, automated tax on every unprotected transaction.

Here’s a sample JSON-RPC config using Flashbots Protect RPC (use on MetaMask or any EVM wallet):

// Add as a custom network in MetaMask > Settings > Networks
{
  "networkName": "Ethereum (Flashbots Protect)",
  "rpcUrl": "https://rpc.flashbots.net",
  "chainId": 1,
  "symbol": "ETH",
  "blockExplorer": "https://etherscan.io"
}
// Transactions are routed privately to block builders,
// bypassing the public mempool entirely.

The fix

Switch your Ethereum RPC to Flashbots Protect for any transaction above your personal threshold for acceptable loss. Transactions sent through this endpoint are routed privately and never exposed to the public mempool. On other EVM chains, check whether an equivalent private RPC service exists; most major L2s now offer one.

4. You’re Signing Permits Without Reading Them

Hardware wallets protect your keys. They don’t protect you from signing a malicious permit.

EIP-2612 permit signatures are gasless off-chain approvals that let a smart contract spend your tokens without a prior on-chain approval transaction. They are widely used by dApps to improve UX. They are also the primary attack vector used by modern wallet drainers, because a permit signature looks like a benign off-chain message to most wallet interfaces, and users sign them reflexively.

When a malicious site asks you to “sign to verify ownership” or “connect to claim your airdrop,” what it may actually be requesting is a permit signature granting unlimited spending rights to an attacker-controlled address. Your hardware wallet won’t stop this. The keys are yours. The signature is yours. The authorisation is legitimate. The target just happens to be an attacker.

What to check before signing any off-chain message.

Look for these fields in the raw signature data your wallet surfaces:

spender — is this an address you recognise?
value — is this scoped to a specific amount, or is it MaxUint256 ?
deadline — when does this authorisation expire?
domain.verifyingContract — does this match the token contract you’re interacting with?

The fix

Use a wallet that decodes and displays permit parameters in human-readable form before you sign. Rabby and recent versions of MetaMask have improved this significantly. Treat any off-chain signature request with the same level of scrutiny as an on-chain approval. If a site is asking you to sign something and you can’t read the fields clearly, you don’t sign it.

5. You Trust the Frontend, Not the Contract

Supply chain attacks against Web3 frontends have become one of the most effective vectors in the space precisely because technically sophisticated users let their guard down on the interface layer. The assumption is that the smart contract is the attack surface, and the UI is just a convenience. This couldn’t be further from the truth.

In a supply chain attack, an attacker compromises a third-party library or CDN that a dApp frontend loads at runtime. The injected script intercepts your transaction parameters and silently modifies the recipient address or contract call before it reaches your wallet. The confirmation your wallet shows you looks legitimate. The transaction it signs does not go where you think it does. Notable examples include compromised versions of the Ledger Connect Kit in late 2023, which briefly affected multiple major dApp frontends simultaneously.

The fix

Build the habit of verifying the contract address in any transaction your wallet surfaces before confirming, even on protocols you use regularly. Bookmark dApp URLs directly rather than navigating via search results or links in Discord. Keep your browser extensions minimal — wallet extensions with broad page permissions can be compromised too. For large transactions, consider interacting directly with a verified contract on Etherscan rather than through a frontend at all.

6. You Have No Recovery Plan That Doesn’t Involve Your Seed Phrase

Photo by rc.xyz NFT gallery on Unsplash

The standard advice — write your seed phrase on metal, store it in two locations, tell no one — is correct as far as it goes. The problem is that it treats recovery as a pure physical security problem. What it doesn’t address is the scenario where the seed phrase itself becomes the attack surface: coercion, inheritance, incapacitation, or the simple reality that the person most likely to access your cold storage in an emergency is also the person you’d want to have access to your funds.

Social recovery, formalised in ERC-4337 account abstraction, separates custody from recovery by letting you designate a set of trusted addresses as guardians. If you lose access, a threshold of guardians can collectively authorise a recovery to a new key. No single point of failure. No seed phrase crossing a network. No trusting one person with everything.

The fix

If you are managing a meaningful amount of value, migrate to or experiment with a smart contract wallet that supports social recovery — Safe (formerly Gnosis Safe) with a multisig setup is the current production-grade standard. For a more personal workflow, wallets implementing ERC-4337 like Ready (Formerly Argent) offer social recovery without requiring all guardians to be co-signers. Pair this with a clearly documented but seed-phrase-free recovery procedure that a trusted person can execute without your direct involvement.

7. Your Dev Environment and Personal Wallet Share an Ecosystem

This is the mistake most commonly made by builders who are also investors, which is a significant portion of the advanced DeFi user base. You’re testing an integration, so you clone a repo, runnpm install, and spin up a local fork. One of the dependencies in that repo has been compromised via a typosquatted package name or a maintainer account takeover. The malicious package scans your environment for private keys, seed phrases, and browser-accessible wallet storage. It finds the MetaMask profile in your browser's user data directory because you use the same machine for development and DeFi.

This is not a contrived scenario. The npm ecosystem has seen a significant increase in targeted crypto-relatedmalicious packages since 2022.

Minimum viable separation

Dedicated browser profile (or separate browser) exclusively for DeFi — no development extensions installed
Hardware wallet for all meaningful transactions, even when it’s slower
Development work is done in a virtual machine (VM) or on a separate physical device if the value at risk justifies it
Never import a private key into a hot wallet on a machine used for development

The fix

Treat your development environment and your DeFi environment as separate security perimeters with no shared credentials. At minimum, use separate browser profiles with separate MetaMask instances and separate seed phrases. For anything beyond experimental funds, use a hardware wallet whose signing device never connects to your development machine. The friction is low. The risk reduction is substantial.

Conclusion

None of these mistakes requires exceptional technical sophistication to exploit. They require patience, on-chain data analysis, and the well-founded assumption that busy, technically literate users cut corners. The consistent theme across all seven is that experience creates confidence, and confidence creates exposure. The users losing the most money in DeFi today are not beginners who don’t know better — they’re people who thought they already did.

Fixing all seven of these at once is a half-day of work. Pick the ones that apply to you and start there. The attacker’s cost is near zero. Your cost of prevention is not.

DEV Community: Joshua Ofamba

I Built a Website Without Paying for Hosting—Here’s What Happened

How IPFS Works for Websites

Build Your Site

The Redeployment Problem

Keep Your Site Online: Three Approaches

1. Self-Hosting

2. Pinning Service

3. Automated Deployment via GitHub Actions

Set up a Custom Domain

Conclusion

the FFmpeg example really hit home. i personally didn't know that the ffmpeg team writes *assembly code by hand* to give us as much as x50 speed up compared to a high-level approach!!

I Tried Contributing to Open Source—And Now I Understand Why People Do It for Free

I Tried Contributing to Open Source—And Now I Understand Why People Do It for Free

1. Your Work Gets Recognized, Permanently

2. It Can Be a Hard Career Requirement

3. The Projects You Use Need You More Than You Think

4. You Get Free Mentorship From Senior Engineers

5. You’ll Build a Network That Opens Doors

Where to Start

7 Web3 Security Mistakes Even Experienced Users Are Still Making

1. You’re Using a Single Wallet for Everything

The fix

2. You’ve Never Audited Your Token Approvals

The fix

3. You’re Broadcasting Transactions Without MEV Protection

The fix

4. You’re Signing Permits Without Reading Them

The fix

5. You Trust the Frontend, Not the Contract

The fix

6. You Have No Recovery Plan That Doesn’t Involve Your Seed Phrase

The fix

7. Your Dev Environment and Personal Wallet Share an Ecosystem

The fix

Conclusion

the FFmpeg example really hit home. i personally didn't know that the ffmpeg team writes assembly code by hand to give us as much as x50 speed up compared to a high-level approach!!