I didn't just build an Airdrop contract. I built a modular Token Distribution System. 🏗️ 1. Merkle Drops for mass scale (Pull). 2. EIP-712 Signatures for dynamic claims (Push). 3. Gasless Support via ERC-2771. Status: Audit-Ready. 🔒 Here is a breakdown of the architecture and

Have you been struggling with diving into the @base ecosystem, build something epic, and actually EARN from it? @Base isn't just an L2, it's a launchpad for creators, devs, and degens to grow the onchain economy while stacking rewards.

I'm Obinna Duru (@BinnaDev), a Smart Contract Engineer. I build secure, gas-optimized protocols like this one. I am actively looking for Internship or Junior Developer roles to contribute to a strong team. To see more of my work on secure and efficient on-chain systems, feel

The code is open-source, fully documented with NatSpec, and ready for review. Check out the repo here: 🔗 https://t.co/nkSspI9JrT I'd appreciate any feedback on the EIP-712 implementation from the senior devs out there!

The Tooling: Foundry I built and tested this entirely in Foundry. Testing wasn't an afterthought: - Fuzz Testing: Validating inputs to prevent edge-case exploits. - Gas Reports: benchmarking the Bitmap vs Mapping savings. - Scripts: TypeScript scripts to generate Merkle Trees

The UX: Gasless Airdrops fail when users have no ETH for gas. I made both modules ERC-2771 Compatible. This allows a Relayer to pay the gas fees on behalf of the user. The contract verifies the _msgSender() correctly, ensuring security even when the transaction is meta-tx

The Logic: Signatures But what if the whitelist changes dynamically? Merkle Trees are too rigid. Enter SignatureAirdrop.sol. Using EIP-712 (Typed Data), a trusted backend can sign permissions off-chain. Users submit the signature to claim. Perfect for "live" rewards or complex

The Logic: Merkle For large static lists (10k+ users), onchain storage is too expensive. I implemented a Merkle Airdrop module. ✅ Storage: O(1). Only the Root is stored on-chain. ✅ Optimization: I used BitMaps (@OpenZeppelin) instead of standard mappings to track claimed

"Gasless" transactions are a lie. 🤥 Someone always pays. But when we build dApps, forcing new users to have ETH just to interact is a failure of design. It breaks trust before it's even built. Here's how we build a thoughtful solution. 👇

Finally, a huge shoutout to the authors and contributors who defined these critical standards. Their thoughtful work makes reliable systems like this possible. Thank you: @drortirosh @wighawag @ethecofund @yoavw @erc4337 @amxx @schin_tomar @stonecoldpat0 @mrnventuro @feindura

Project Repo: https://t.co/AqJZNSAOzQ If you find this thoughtful, a Like & Repost is always appreciated. To see more of my work:

I built a secure, gasless Merkle Airdrop contract to explore this exact philosophy. I've written a full deep-dive on https://t.co/yaMVEnDAlu with all the code and security considerations. Full Article:

This is engineering with purpose. We aren't just using a standard; we're making a deliberate choice to build systems that are reliable, secure, and user-focused. We must build systems that are not only functional, but thoughtful and excellent. That is how we build trust.

...AUTHORIZE: Our contract, seeing the call is from the TrustedForwarder, uses _msgSender() to securely extract Alice's address. Authorization is preserved.

The flow is built on trust and verification: SIGN: Alice signs a message with her intent (it's free). RELAY: Bob (the relayer) pays gas to submit her signed message to a single TrustedForwarder contract. ...

This is not a new problem. The principled, reliable solution is ERC-2771. It's a community-driven standard that provides an on-chain protocol to securely separate the gas payer (the relayer) from the action authorizer (the user).

So, we create a "relayer" (Bob) to pay the gas for her. Problem solved? No. Now msg.sender = Bob. Our contract's security (require(msg.sender == Alice)) breaks. We've traded a thoughtful UX for a massive security hole.

Imagine Alice. She's excited to claim her first airdrop. She clicks "Claim", but the transaction fails. Why? The "Empty Wallet" problem. She has no ETH for gas. Her excitement turns to frustration. Our system has failed her. This isn't reliable or excellent.

This project was a personal statement - an attempt to build a portfolio that lives up to the same standards I apply to my smart contract work. It's more than a portfolio, it's my new digital home. Let's build something you can trust 🤝. 👉Check it out: https://t.co/RPa0G12zOn

🔵 Excellent: The Polish & Performance "Excellence" is in the craft. This isn't a template. - Built on @nextjs 14, @typescript, & Server Components. - Scores 95+ on Lighthouse. - Every interactive element has a precise, deliberate motion. It feels fast, balanced, and complete