Cap what a vault can pay out in one transaction.

You do not have write access to Andre's repo, and you should not want it. The standard open-source flow is: fork it into your own account, work on a branch there, then ask the maintainer to pull your branch in.

1 · Fork on GitHub

Open github.com/ASCorreia/solana-fall-vault and click Fork (top right). That creates github.com/<you>/solana-fall-vault — a full copy under your account that you own completely.

2 · Clone your fork, not the original

git clone https://github.com/<you>/solana-fall-vault.git
cd solana-fall-vault

3 · Add the original as upstream

Your clone knows about your fork (origin) and nothing else. Adding the original as a second remote lets you pull in changes the maintainer makes while you work.

git remote add upstream https://github.com/ASCorreia/solana-fall-vault.git
git remote -v

# origin    https://github.com/<you>/solana-fall-vault.git   (fetch/push)
# upstream  https://github.com/ASCorreia/solana-fall-vault.git (fetch/push)

4 · Branch before you touch anything

git switch -c feat/max-withdraw

Never do the work on main. Two concrete reasons: your main stays a clean mirror of upstream so you can sync it at any time, and a PR opened from main is painful to update or reuse for a second contribution.

5 · Build and run the existing tests

anchor build
cargo test

All existing tests should pass before you change a line. If they do not, fix your environment first — you cannot tell your breakage from theirs otherwise.

Here is a map of the repo for you, give it a read and check back when you are struggling on finding where you need to make changes

Read these two before continuing

initialize.rs — see how set_inner writes the whole struct at once. Adding a field means this call stops compiling until you supply it, which is Rust doing you a favor.

withdraw.rs — see how the vault PDA signs for itself via signer_seeds. Your check goes in before that transfer ever happens.

What this does. Gives every vault somewhere to remember its own limit. The cap belongs in state, not in a constant — different vaults should be able to have different ceilings.

Add max_withdraw: u64 to VaultState.

You do not need to touch space = in initialize.rs. The struct derives InitSpace, and VaultState::INIT_SPACE recalculates itself. That is the entire reason that derive exists.

What this does. Lets the caller choose the cap when they create the vault, and writes it into state.

Two edits, and they must agree:

1. initialize_vault in instructions/initialize.rs takes a new max_withdraw: u64 parameter and passes it into set_inner.
2. The initialize wrapper in src/lib.rs takes the same parameter and forwards it.

Miss the second and nothing compiles — the wrapper calls a function whose signature no longer matches. That is the routing layer earning its keep.

What this does. Gives the failure a name and a message a caller can actually act on.

error.rs currently holds one placeholder variant with the message "Custom error message". Add a real one — something like ExceedsMaxWithdraw with a message that says what went wrong.

Leave the placeholder CustomError where it is. Deleting it would shift every error code after it, and it is not yours to remove in this PR.

What this does. Rejects any withdrawal larger than the vault's limit, before any lamports move.

In withdraw_lamports, compare amount against ctx.accounts.vault_state.max_withdraw and bail with your new error if it is larger.

Requirements

1. The check runs before the CPI transfer, not after.
2. amount == max_withdraw is allowed. It is a limit, not a strict bound.
3. Use require! with your custom error, not a bare panic! or assert!.

Changing an instruction's arguments changes its serialized data, so every test that builds an initialize instruction is now wrong. The compiler will list them; here is the whole set up front.

In tests/common/mod.rs

• build_initialize_ix takes a max_withdraw: u64 and passes it into Initialize { max_withdraw }.
• initialize_vault (the convenience wrapper) takes it too and forwards it.

For the tests that are not about the limit, pass something generous — 100 * ONE_SOL — so the cap never interferes with what they were written to check. A deposit test failing because of a withdrawal ceiling would be a bad test.

The challenge names them, and the middle one is the point:

1. A valid withdrawal — under the cap, succeeds.
2. Exactly at the limit — amount == max_withdraw, succeeds.
3. Over the limit — one lamport more, fails.

Two and three are a boundary pair. Together they pin down exactly where the line sits, and they are the only tests that can tell <= from <. A suite with only "works" and "obviously too much" passes for both implementations, one of which is wrong.

Shape of each test

1. Fresh setup_svm(), fresh Keypair, fund it.
2. initialize_vault with a cap you choose — pick a round number you can reason about, like 2 * ONE_SOL.
3. Deposit enough that the vault can actually cover the withdrawal. A rejection because the vault was empty proves nothing about your cap.
4. Attempt the withdrawal and assert on the result.

A pull request is a request, addressed to a person. Everything below is about making that person's job easy.

1 · Check what you are about to commit

git status
git diff

2 · Commit in logical pieces

git add programs/lamports-vault/src
git commit -m "Add per-transaction withdrawal limit to vault state"

git add programs/lamports-vault/tests
git commit -m "Test withdrawal limit at, under, and over the cap"

Imperative mood — "Add", not "Added" or "Adding". It reads as an instruction to the codebase, which is the convention git itself uses. Two focused commits beat one final changes, and beat nine commits called fix.

3 · Sync with upstream before you push

git fetch upstream
git rebase upstream/main

If the maintainer changed anything while you worked, this replays your commits on top of their latest. Doing it now means resolving conflicts on your own time instead of being asked to in review.

4 · Push to your fork

git push -u origin feat/max-withdraw

To origin — your fork. You have no write access to upstream, and a push there will be rejected.

5 · Open the pull request

GitHub shows a "Compare & pull request" banner on your fork right after the push. Check the direction carefully before submitting:

6 · Write a description worth reading

## What
Adds a per-transaction withdrawal limit to the lamports vault.

## Why
The vault currently allows draining the full balance in a single
withdraw. A per-transaction cap bounds the damage from a leaked key
or a buggy client.

## How
- `max_withdraw: u64` appended to `VaultState` (appended, not
  prepended, so the byte offsets `test_initialize` asserts on stay valid)
- set from a new `initialize` argument
- `withdraw` rejects `amount > max_withdraw` with `ExceedsMaxWithdraw`

## Testing
`anchor build && cargo test` — all existing tests pass, plus three new
ones covering under, exactly at, and one lamport over the cap.

Explain the why and any non-obvious decision. The field-order note is exactly the kind of thing that earns trust: it shows you understood a consequence a reviewer would otherwise have to catch.

7 · After you submit

• Leave "Allow edits by maintainers" checked. It lets them push a small fix instead of asking you for one.
• Respond to review by pushing more commits to the same branch — the PR updates itself. Do not open a second PR.
• Do not force-push once review has started unless asked; it invalidates the comments people have already left.
• Reply to every comment, even just to say you have done it. Silence reads as disagreement.

Let the compiler walk you through it first. Most of this challenge is Rust telling you precisely what is broken, and reading a solution skips the part where you learn to read those messages.