Make an offer the maker cannot instantly retract.

You cannot push to the original repo, and you should not want to. The standard open-source flow is: copy 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/decentra1ized/solana-fall-t22-escrow and click Fork (top right). You now own github.com/<you>/solana-fall-t22-escrow.

2 · Clone your fork — not the original

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

3 · Add the original as upstream

git remote add upstream https://github.com/decentra1ized/solana-fall-t22-escrow.git
git remote -v

# origin    https://github.com/<you>/solana-fall-t22-escrow.git   (yours — you push here)
# upstream  https://github.com/decentra1ized/solana-fall-t22-escrow.git (theirs — you pull from here)

4 · Branch before you touch anything

git switch -c feat/escrow-timelock

Never work on main. Your main stays a clean mirror of upstream so you can sync it whenever you like, and a pull request opened from main is awkward to update or reuse later.

5 · Build, then test

anchor build
cargo test

One test exists (test_make) and it should pass before you change anything. If it does not, fix your environment first; you cannot tell your breakage from theirs otherwise.

Read README.md first — it walks through every account in every instruction. Then come back for the map.

Three instructions

Two accounts hold the deal

escrow — a PDA derived from ["escrow", maker, seed]. It stores the terms: who, which mints, how much of each, and the bump. The seed is a u16 the maker picks, so one person can run several offers at once.

vault_a — a token account whose authority is the escrow PDA. This is where the maker's token A actually sits. Because a PDA owns it, no human can move those tokens; only the program can, and only by the rules written in it.

The files

Unlike the last assignment, lib.rs stays untouched here. You are adding a field and a check, not changing any instruction's arguments — so nothing ripples outward. Fewer files, more thinking.

What this does. Gives each escrow somewhere to record when it was born, so cancel can work out how old it is.

Add a created_at: i64 field to the Escrow struct in src/state/escrow.rs.

Why i64 and not u64

Solana's unix_timestamp is a signed 64-bit integer — seconds since 1970, where negative means before 1970. You will never see a negative one here, but matching the type the runtime gives you avoids a cast, and casts are where sign bugs are born. Use the type the source uses.

You do not need to change space = 8 + Escrow::INIT_SPACE in make.rs. The struct derives InitSpace, which recomputes the size for you. That derive is doing real work — 8 more bytes of rent, calculated automatically.

What this does. Records the current time into the escrow at the moment it is created.

In make.rs, the handler calls set_inner with a fully populated Escrow. Add your new field there, filled from Solana's clock.

Where does a program get the time?

Not from the operating system — a program has no OS. Solana exposes a sysvar called Clock, a special account the runtime keeps updated with the current slot, epoch, and a unix_timestamp agreed by validators.

let now = Clock::get()?.unix_timestamp;

Clock is already in scope through anchor_lang::prelude::*, which make.rs imports. Nothing to add.

What this does. Names the failure, so a caller sees "the time lock has not elapsed" instead of "transaction failed."

error.rs has one placeholder variant with the message "Custom error message". Add a real one — something like TimeLockActive, with a message that tells the user what happened.

Leave the placeholder where it is. Anchor numbers error variants in declaration order, so deleting one shifts the codes of everything after it — and it is not yours to remove in this pull request.

Put the five minutes in constants.rs

constants.rs currently holds one unused SEED. Add your delay there rather than writing 300 inline in the handler:

#[constant]
pub const CANCEL_DELAY_SECONDS: i64 = 300; // 5 minutes

What this does. Refuses to cancel until five minutes have passed since the escrow was made.

In cancel.rs's handler, read the clock, work out when the escrow unlocks, and reject anything earlier.

Requirements

1. The check runs first — before any tokens move.
2. Exactly at the boundary is allowed. Five minutes have passed means now >= created_at + 300.
3. Use require! with your custom error.
4. Add the delay with checked_add, not +.

You need two tests, and they are the whole point of the assignment:

1. Too early — cancel right after make, expect rejection.
2. Late enough — advance the clock past five minutes, expect success.

A third is worth adding if you have the appetite: cancel at exactly created_at + 300, which must succeed. That one pins the boundary, and it is the only test that can tell >= from >.

Waiting five real minutes is not the answer

LiteSVM lets you set the clock directly. The instinct is to reach for warp_to_slot — and it will not work:

// Moves the slot. Leaves unix_timestamp exactly where it was.
svm.warp_to_slot(1_000_000);

Verified: after warping a fresh LiteSVM to slot 1,000,000, unix_timestamp was still 0. Slots and wall time are separate fields, and only one of them is what your program reads.

What does work:

use anchor_lang::prelude::Clock;

let mut clock = svm.get_sysvar::<Clock>();
clock.unix_timestamp += 301;
svm.set_sysvar(&clock);

Two things about a fresh LiteSVM

A new LiteSVM starts at unix_timestamp = 0. So the created_at your make stores will be 0, and you are advancing from zero, not from today's date. Print it once if that feels strange — seeing it is faster than reasoning about it.

Also: setting the sysvar changes the clock from that point on. Make the escrow first, then move the clock, then cancel. Moving it before make just changes what gets stamped in.

Getting the setup you need

Create tests/test_cancel.rs and copy setup_mint and setup_token_account from test_make.rs. Yes, copying is allowed — Rust compiles each file in tests/ as its own crate, so they genuinely cannot see each other's helpers without a shared mod.

let err = res.unwrap_err();
let logs = err.meta.logs.join("\n");
assert!(logs.contains("TimeLockActive"), "expected the time lock error, got: {logs}");

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

1 · Look before you stage

git status
git diff

2 · Two commits, not one

git add programs/escrow/src/state programs/escrow/src/instructions/make.rs \
        programs/escrow/src/error.rs programs/escrow/src/constants.rs \
        programs/escrow/src/instructions/cancel.rs
git commit -m "Add five minute time lock before escrow cancellation"

git add programs/escrow/tests
git commit -m "Test cancellation before and after the time lock"

Imperative mood — "Add", not "Added". The feature and the tests are two separate ideas, and a reviewer should be able to read them separately.

3 · Sync before you push

git fetch upstream
git rebase upstream/main

This replays your commits on top of whatever the maintainer has done since. Resolve conflicts now, on your own time, rather than being asked to mid-review.

4 · Push to your fork

git push -u origin feat/escrow-timelock

5 · Open it in the right direction

6 · Write a description worth reading

## What
Escrows can no longer be cancelled for 5 minutes after creation.

## Why
An offer that can be withdrawn instantly is a free option for the maker,
and it lets them cancel in front of a taker who has already paid a fee.
A minimum lifetime makes the offer credible.

## How
- `created_at: i64` appended to `Escrow`, stamped from `Clock` in `make`
- `cancel` rejects with `TimeLockActive` until `created_at + CANCEL_DELAY_SECONDS`
- delay lives in `constants.rs` and is exported to the IDL

## Testing
`anchor build && cargo test` — `test_make` still passes, plus new tests
for cancelling too early, exactly at the boundary, and after the lock.

7 · After you submit

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