From Frontend Developer to CodeHawks Eagle

Al-Qa'qa' was studying computer engineering in Egypt and made a pivotal decision: leave web development and enter the world of blockchain security. Today, he uncovers critical vulnerabilities in smart contracts, helping to secure digital assets worth billions of dollars across the Ethereum and Solana ecosystems.

This is the story of how determination, consistency, and a hunger for learning transformed Al-Qa'qa' from a front-end developer into a professional smart contract auditor and CodeHawks Eagle in just 18 months.

My path to smart contract security

I developed an early interest in blockchain while studying computer engineering. Although I enjoyed development, what truly captured my attention was something else: the vulnerabilities. 

As I built applications, I found myself increasingly drawn to the question not of how things worked, but how they could fail. I became fascinated by the security side of technology. I was curious about the attacks, the bugs, and the ways systems could break. 

At the time, I hadn’t formally studied cybersecurity. It was more of an obsession than a skill. But once I started learning about blockchain hacks, how a single flaw in a smart contract could lead to the loss of millions, I was hooked. The idea that a few lines of faulty logic could have such a significant impact was both terrifying and fascinating.

Making the switch wasn’t easy. It meant starting over after already investing significant time and resources into frontend development. But the responsibility of securing protocols that manage real money resonated with me, and I committed fully.

In 1.5 years since making the switch, I’ve gained experience across Ethereum Virtual Machine (EVM)-based contracts and Solidity, as well as Rust and Solana. This helped me build a foundation that now supports my work as a blockchain security auditor.
‍

Why security matters and how I approach it

In smart contracts, code is custody. There’s no central authority to reverse malicious transactions, there are no safeguards. Only immutable code, freely available for people to interact with. That makes correctness not just important, but essential. The consequences of a single vulnerability can ripple across millions of users and billions of dollars worth of assets.‍
‍
That’s why my advice is:

• For developers: Write secure, test-driven contracts and never deploy without a rigorous audit. Maybe more than one.
  
  
• For security teams: Don’t cut corners. Invest time and money in building relationships with skilled researchers who can identify impactful bugs.
  ‍

My approach to success

My progress came down to three things: consistent practice, focused effort, and patience. Success comes from deep learning and persistence. Don’t take shortcuts, which often lead to disaster.

When starting an audit, I always study the protocol’s documentation first. Understanding how it’s meant to work helps me spot where things could go wrong. I prefer a manual review process to build familiarity with the protocol and allow my intuition to guide me, which helps me uncover subtle issues that automated tools may miss.
‍

Becoming a CodeHawks Eagle

Earning the CodeHawks Eagle badge was a major turning point in my journey. It validated not only my skills but also my decision to pursue full-time smart contract security. 

I initially found CodeHawks through Patrick Collins’ YouTube channel while exploring web3 education. The platform gave me the chance to prove myself and grow.

By the time CodeHawks launched, I had already gained some solid experience in the field, but the platform gave me the chance to test those skills in real-world, competitive environments.

One of the key moments came during the ArkProject: NFT Bridge contest. It was only my second contest on CodeHawks, and yet it was a breakthrough moment for me. I identified impactful vulnerabilities that propelled me from the bottom of the leaderboard all the way up to rank 13. 

That performance played a significant role in qualifying me for Eagle status, which opened the door to steady audit work and collaboration opportunities with other top-tier researchers, including the Cyfrin Audit team.

What keeps me engaged is the weight of the responsibility. When auditing protocols with millions of dollars at stake, there’s no room for guesswork. I also enjoy the variety as each audit brings new codebases, languages, and logic puzzles. It’s always fresh, always new, and never repetitive.
‍

How I solved a critical token mismatch

One of my most significant discoveries involved a critical L2Bridge issue related to ERC-721 token compatibility. The problem arose from differing return types: older tokens (pre-March 2024) used felt252 for strings, while newer ones returned ByteArray.

The bridge was built for ByteArray, making it incompatible with the majority of NFTs on the network and breaking a key feature: bridging NFTs between Layer 2 and Layer 1.

Here’s how the name() function changed across OpenZeppelin versions, creating the incompatibility:
‍

// Pre-v0.9.0 (felt252)
fn name(self: @ComponentState<TContractState>) -> felt252 {
    self.ERC721_name.read()
}

// Post-v0.10.0 (ByteArray)
fn name(self: @ComponentState<TContractState>) -> ByteArray {
    self.ERC721_name.read()
}

‍

The vulnerability was rooted in high-level interface calls that failed when interacting with legacy tokens:
‍

// Problematic high-level interface calls expecting ByteArray
Option::Some(
    ERC721Metadata {
        name: erc721.name(),      // This fails with older tokens
        symbol: erc721.symbol(),  // This fails with older tokens
        base_uri: "",
        uris
    }
)

‍

It could be fixed with low-level contract calls that gracefully handle both formats:
‍

// Recommended approach using low-level calls
match starknet::call_contract_syscall(
    collection_address,
    name_selector,
    calldata,
) {
    Result::Ok(span) => span.try_into(),  // Works for both felt252 and ByteArray
    Result::Err(_e) => {
        // Fallback handling
    }
}

Discovering and resolving this issue required connecting protocol history with real-time architecture, something made possible only with a deep understanding of the protocol.
‍

Lessons from the frontlines: advice for aspiring blockchain auditors

If you’re starting your journey in web3 security, or considering one:

• Build a strong foundation before jumping into contests: Complete courses on Updraft and participate in First Flights on CodeHawks. These will give you the fundamentals you need to be effective in real audits.
  
  
• Stay focused and don’t spread yourself too thin: Choose one protocol or contest that interests you and dive deep. Read the docs, study similar codebases, and review past audits. Focus builds the kind of insight that general exposure doesn’t.
  
  
• You’ll miss issues at first, so learn from them: After each contest, compare your findings with the final reports. Use Solodit to review validated bugs. Understanding what you missed and why is key to improving.
  
  
• Study real audit work: Read write-ups, peer reviews, and post-mortems. Learn how experienced auditors think and structure their reports. It’s one of the fastest ways to level up.
• Practice consistently and pace yourself: Progress comes from steady, repeated effort. Each audit builds on the last. Just keep showing up and pushing your understanding further.

My journey from frontend development to security research has been challenging, rewarding, and definitely worth it. What began as curiosity has become a career protecting real people’s assets in the emerging digital economy. If you’re considering a similar path, stay persistent. With effort and intention, you can build a meaningful career in smart contract security.

Feel free to follow me and message me if you need help starting as a security researcher.