locked proofs

Chapter 3 had a catch: by default, anyone can verify your proof and close it. Fine for receipts. Bad for anything adversarial, like an escrow or a bet, where a stranger closing your proof early ruins the game. prove_by fixes that.

the verifier lock

When you create a proof with prove_by, you can name a required verifier: one exact wallet address. From then on:

• Only that wallet, actually signing, can verify the proof. Everyone else gets UnauthorizedVerifier.
• The lock can be a program's address too. There's a twin instruction, verify_by, that lets a program be the verifier while a normal wallet pays the fees. Receipts for robots, really.
• Expire ignores the lock. After the timer, anyone can still sweep the proof. On purpose: a lost verifier key should never trap a deposit on chain forever.

the notes field

prove_by can also attach metadata: raw bytes stored right inside the proof account, after the main fields. This is why the bigger account sizes from chapter 2 exist. Roughly: about 210 bytes of notes fit in the base size, about 650 in standard, and about 2,100 in premium.

Two rules about the notes, and they're both sharp:

1. The program never reads them. No checking, no validation. They're a sticky note, not a contract. Your app gives them meaning.
2. They're public and permanent, like everything else on chain. Same rule as chapter 2: hash anything sensitive.

builder recipes

• Escrow check-ins. User proves a commitment, your program is the locked verifier, and settlement is the verify call.
• Oracle attestations. A bot proves data with metadata describing the feed, locked to your settlement program.
• Sealed-bid anything. Bidders prove hashed bids locked to the auction program; reveals happen as verifies.