You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CLAUDE.md
+17-9Lines changed: 17 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -196,13 +196,7 @@ await client
196
196
197
197
Do NOT use `advanceBySlots()` for this purpose - it changes the clock which may affect time-dependent tests.
198
198
199
-
**Token amounts in tests:** Use easy-to-read round numbers like hundreds or thousands of tokens. Our standard mint decimals is 6, so:
200
-
- 100 tokens = `100_000_000` (100 * 10^6)
201
-
- 1,000 tokens = `1_000_000_000` (1000 * 10^6)
202
-
203
-
This makes test assertions and calculations much easier to verify at a glance.
204
-
205
-
**Isolating tests during development:** When developing or debugging tests, use `.only` to run only the tests you're working on:
199
+
**Isolating tests during development:** When writing or editing tests, ALWAYS add `.only` to the `describe`/`it` block you're working on before running. This keeps feedback fast and output clean. Once your changes pass, remove `.only` and run the full suite (`anchor test --skip-build`) to confirm nothing else broke.
206
200
207
201
```typescript
208
202
// Run only this specific test
@@ -216,8 +210,6 @@ describe.only("#split_tokens", function () {
216
210
});
217
211
```
218
212
219
-
This significantly speeds up iteration and makes test output easier to read. Remember to remove `.only` before finishing development.
220
-
221
213
**Assertion messages:** Do not include assertion messages for better readability. The assertion itself should be clear enough:
222
214
223
215
```typescript
@@ -231,6 +223,22 @@ assert.equal(recipientBalance.toString(), "500000000", "Recipient should have 50
231
223
232
224
Exceptions: Keep messages in `expectError()` calls and `assert.fail()` within try-catch blocks, since those are part of error handling patterns and help identify which check failed.
233
225
226
+
227
+
**Token amounts in tests:** Use easy-to-read round numbers like hundreds or thousands of tokens. Our standard mint decimals is 6, so:
228
+
- 100 tokens = `100_000_000` (100 * 10^6)
229
+
- 1,000 tokens = `1_000_000_000` (1000 * 10^6)
230
+
231
+
This makes test assertions and calculations much easier to verify at a glance.
232
+
233
+
### Solana Reentrancy Guard
234
+
The Solana runtime prevents a program from appearing more than once in the same CPI stack. This affects two patterns in our codebase:
235
+
236
+
1.**futarchy → squads → futarchy** (e.g., admin-executing a DAO config change): Futarchy cannot CPI into Squads to execute a vault transaction whose inner instructions CPI back into futarchy. Workaround: futarchy only approves/validates the Squads transaction, then the client executes it as a separate top-level transaction.
237
+
238
+
2.**squads → futarchy → squads** (e.g., a team multisig that is itself a Squads wallet): If a Squads-initiated transaction calls a futarchy instruction that needs to CPI into Squads, the runtime will reject it. Workaround: have futarchy validate pre-created Squads accounts on-chain instead of creating them via CPI.
239
+
240
+
When designing instructions that involve Squads CPIs, check whether either pattern applies and flag it early. The general solution is: split the operation across multiple transactions — validate/approve in one, execute in another.
0 commit comments