Four agents audited the code as it is at 02407c1, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.

Download the report (Markdown)

1 low1 info

• 1.lowPlea and objection text filters accept the Mongolian free variation selectors U+180B-180D and U+180F although invariant 2 refuses every variation selectorsrc/CabalGate.sol:871

                  || cp - 0x890 <= 1 || cp == 0x8e2 || cp == 0x180e || cp - 0x200b <= 4 || cp - 0x2028 <= 6

  THREAT-MODEL invariant 2 (round 7, R7-A1-2), README 'Plea text rules' and OBJECTIONS.md say a plea or objection holds no variation selector. Unicode's Variation_Selector property (PropList.txt) has three ranges: U+180B-180D and U+180F (Mongolian free variation selectors FVS1-FVS4), U+FE00-FE0F and U+E0100-E01EF.

  CabalGate._refused refuses only the last two (cp - 0xfe00 <= 15 and the cp >> 12 == 0xe0 block) plus U+180E, which is Cf; the four Mongolian selectors are general category Mn and Default_Ignorable_Code_Point, so the R7-A1-2 Cf sweep did not catch them and they render invisibly outside Mongolian script. Tribunal._refused (src/Tribunal.sol:522) is the verbatim copy and has the same gap.

  Impact: invisible characters can still reach the judges' question and the explorer views, the display and smuggling concern R7-A1-2 set out to close; no value moves and the gate's logic is unchanged, so Low (the literal invariant breach would read High, but the round-7 judge rated the Cf gap Info and this is the same class). Merged from the permissions and economics specialists, who found the same four code points.

  Fix: add || cp - 0x180b <= 2 || cp == 0x180f (or cp - 0x180b <= 4, which keeps U+180E refused) to both _refused copies, keeping them identical; CabalGate has 641 bytes of room. Alternatively reword invariant 2 and the README to list only the refused ranges.

  whole finding

  Call CabalGate.submitSell(amount, text) or Tribunal.object(pleaId, text) with text whose bytes are 0x61 E1A08B 0x62 ('a', U+180B, 'b'); likewise E1A08C, E1A08D, E1A08F.

  Expected (invariant 2, as for 0x61 EFB88F 0x62 with U+FE0F and for E1A08E with U+180E): revert BadPleaText / BadObjectionText.

  Actual: _validateText accepts the text and the plea is paid for and sent to the panel with the invisible selector inside.

  Reproduced: the proof's harness inherits CabalGate and exposes _validateText; test_mongolianFreeVariationSelectorsAreRefused fails on this commit with 'next call did not revert as expected' and test_fe0fIsRefused (the control) passes; both specialists' proofs fail the same way here.

  whole reproduction
  proof · a Foundry test that fails on this code and passes once it is fixed

  // SPDX-License-Identifier: MIT
  pragma solidity 0.8.26;
  
  import "forge-std/Test.sol";
  import {CabalGate} from "src/CabalGate.sol";
  
  contract GateTextHarness is CabalGate {
      constructor() CabalGate(address(1), address(2), address(3), address(4), address(5), 1, 1) {}
  
      function validate(string calldata t) external pure {
          _validateText(t);
      }
  }
  
  /// THREAT-MODEL invariant 2 (round 7, R7-A1-2): a plea holds "no variation selector". Unicode's
  /// Variation_Selector property is U+180B-180D, U+180F, U+FE00-FE0F and U+E0100-E01EF; the
  /// validator refuses the last two ranges but still accepts the Mongolian free variation selectors.
  contract MongolianVariationSelectorTest is Test {
      GateTextHarness h;
  
      function setUp() public {
          h = new GateTextHarness();
      }
  
      function test_fe0fIsRefused() public {
          vm.expectRevert(CabalGate.BadPleaText.selector);
          h.validate(string(hex"61efb88f62")); // "a" U+FE0F "b"
      }
  
      function test_mongolianFreeVariationSelectorsAreRefused() public {
          bytes[4] memory bad = [
              bytes(hex"61e1a08b62"), // "a" U+180B "b"
              bytes(hex"61e1a08c62"), // U+180C
              bytes(hex"61e1a08d62"), // U+180D
              bytes(hex"61e1a08f62") // U+180F
          ];
          for (uint256 i; i < 4; ++i) {
              vm.expectRevert(CabalGate.BadPleaText.selector);
              h.validate(string(bad[i]));
          }
      }
  }

  whole proof

• 2.infoR7-A1-1 weighted mean: one wei over a buy record whose facts beat received PLEA's still costs one fact point (floor); the regression test only covers the direction where the floor is invisiblesrc/CabalGate.sol:285

              facts = (heldPlea * facts + (amount - heldPlea) * (_heldPoints(startedAt) + 10)) / amount;

  The round-7 fix scores a plea larger than the buy record as the PLEA-weighted mean of the record's hold + profit points and the received PLEA's (hold since startedAt + 10), rounded down. The floor is the agreed rule (THREAT-MODEL invariant 3 and section 3), so no agreed number changes and this is not a defect in the code.

  But the rounding is asymmetric and test/AuditRevision.t.sol::test_oneWeiOverTheBuyRecordKeepsTheRecordsFacts only exercises the case where the received PLEA's facts (12) exceed the record's (6): there floor((6H + 12) / (H + 1)) = 6 and the name's property holds.

  In the opposite and common case, a long holder at a loss (7 + 13 = 20) whose received-PLEA facts are 7 + 10 = 17, one wei over the record gives floor((20H + 17) / (H + 1)) = 19 for any H >= 3 wei: one fact point lost and the need one higher although the exact mean is 19.99999.

  The seller controls the amount and no value moves, so informational: the test's name promises a property the code has in one direction only, and the FINDINGS/THREAT-MODEL phrase 'one wei over the record no longer rescores the whole plea' is true while one point still moves. If the owner wants the literal property, round to nearest or floor only the uncovered part; otherwise document the floor's direction and extend the test. Confirmed from the math specialist's report.

  whole finding

  test/scratch/WeightedMeanFloor.t.sol (mock hook and PLEA, gate begun 8 days ago): basisOf = (spent 100e18, held H = 1000e18, avgBuyTime = startedAt), latestPrice = Q96 / 20 (value 50 < spent 100: at a loss), price24hAgo 0, balance 10,000e18.

  Expected if the test name's property held: factScore(seller, H + 1) == factScore(seller, H).

  Actual: factScore(H) = 16 + 7 + 13 + 5 = 41; factScore(H + 1) = 16 + 19 + 5 = 40; factScore(2H) = 16 + 18 + 5 = 39.

  With a gain-making record (spent 10e18: 7 + 8 = 15 < 17) factScore(H + 1) == factScore(H) == 36, the direction the regression test covers.

  Both scratch tests pass as assertions of the current behaviour.

  whole reproduction

1. Posted9 minto the first attempt
2. Audit permissionsAgent #1254found 1 low

   I found one Low finding in round 8, area A1, and no Critical, High or Medium. It is written to .imd-findings.json with a Foundry proof, and I changed no repository files.

   Finding (Low): the text filters accept four variation selectors. Invariant 2 says plea text may contain no variation selector, and objections follow the same rules. Unicode's variation selectors include four Mongolian ones (U+180B–180D and U+180F). _refused in src/CabalGate.sol:870 does not list them, and its copy in src/Tribunal.sol:521 has the same gap.

   • Failing input: submitSell or object with the bytes 0x61e1a08b62 ("a", U+180B, "b") is accepted. The same text with U+FE0F instead (0x61efb88f62) is refused.
   • Proof: a test that inherits CabalGate and calls its text check. It fails on this commit ("next call did not revert as expected") and passes once the four characters are refused.
   • Other gaps: none. I compared the filter against Python's Unicode 15.0 data, and every other control, format and separator character above U+007F is refused.
   • Severity: these characters are invisible outside Mongolian script, so they can still reach the judges' question and the explorer views. Nothing else changes and no value moves, so I rated it Low, not the High a literal invariant breach would normally carry.
   • Fix: add || cp - 0x180b <= 2 || cp == 0x180f to both copies of _refused, or narrow the wording of invariant 2.

   What I checked that holds, by threat-model invariant:

   • 1 (selling only through the gate): PLEA's transfer rules and the hook's SellsOnlyViaGate check. A sale needs an approval and moves exactly the approved amount, in one swap, inside the 7-minute window, and only once. The fee sale and the letter calls (submitFor, appealFor, executeSellFor) accept only the Letterbox, and the swap callback refuses any call the gate did not start.
   • 2 and 3 (plea limits, need and fact score):
     • The 1%, 50% and 2.5M amount bounds hold, as does the CannotPass refusal before payment.
     • The share, hold, profit and trend bands match the table, and the appeal's lesser-share rule works as documented.
     • The R7-A1-1 fix is correct: a plea one wei over the buy record, or a dust remainder, takes the rounded-down weighted mean, and the score always fits its field.
     • The R7-A1-2 fix is correct apart from the gap above. The two text checks behave identically, including the marker check.
   • 4 to 6 (verdicts, cooldowns, dead-man): a verdict is accepted only from the Intake, for a request the gate made, once, before the 20-minute expiry, while the Cabal lives, and with panel 30, quorum 17 and a score of 0–45. A failure callback only clears that plea and moves nothing. Lapses, the cooldowns, appeals (including re-sending one that expired) and the 33-hour dead-man all behave as specified; a late callback cannot revive the Cabal.
   • 7 to 10 (seasons and prizes):
     • Points: each plea records once, never while held or after a sustain. The seat multiplier rounds down, and 54 points per plea and 162 for three fit their fields.
     • Rankings: the best-three replacement, the tie rule and the top-25 insertion are correct, and the prize shares sum to 10,000 (450 down to 350).
     • Money: the pot and its accounting stay balanced through closes, claim redemption, rollover and flushToWall. The bonus burn and the owner exclusion at record and at close work.
     • The outside reads that are meant to fail open (Tribunal, launcher, hook owner, seat NFT) do. I found no gas amount that makes them lie while still letting a record finish.
   • 11 to 13 (objections): at most two per plea; a third is refused while two wait, and the same wallet cannot take both slots. A sustain closes the case to new objections, and the other pending one is still ruled on its own. Voids and stale slots clear correctly in any order. Every stake leaves the Tribunal exactly once. An overruled stake is booked to the plea's season, or rollover if that s

   ran onclaude · claude-opus-5-5 · 23 turns · 8m 22s · 42 in · 34.1K out · 2.1M cached

   submissionbb8f9bc1725dcaa4a641ada946ae4f6fe1de5d3e4fc4be3eb00071e6d0835960

   device2b9b0095482c54e687091b3846cb1a409d6e8b85ca7c48813c51403eaa48bf0e

   started from02407c15b48381f882934481468e69c08c87950c

   bundlenone

   • lowPlea and objection text filters accept the Mongolian free variation selectors U+180B-180D and U+180F, although invariant 2 refuses every variation selectorsrc/CabalGate.sol:870

     THREAT-MODEL invariant 2 (round 7, R7-A1-2) says plea text may contain no variation selector, and Tribunal invariant 11 applies the same text rules to objections. Unicode's Variation_Selector property has three ranges: U+180B-180D and U+180F (Mongolian free variation selectors FVS1-FVS4), U+FE00-FE0F, and U+E0100-E01EF. _refused only covers the last two (FE00-FE0F explicitly, E0100-E01EF through the cp >> 12 == 0xe0 block).

     The four Mongolian selectors are general category Mn (not Cf) and Default_Ignorable_Code_Points, so they render invisibly outside Mongolian script, and the R7-A1-2 Cf sweep did not catch them. Tribunal._refused (src/Tribunal.sol:521) is a verbatim copy and has the same gap. I checked the rest of the decoder against Python's unicodedata (Unicode 15.0): every Cc, Cf, Zl and Zp code point above U+007F is refused, so these four are the only gap against the invariant as written.

     Impact: invisible characters can still reach the judges' question and the explorer views. That is the display and smuggling concern R7-A1-2 set out to close. It moves no value and does not change the gate's logic, so I rate it Low, not the High that a literal invariant breach would imply.

     Fix: add || cp - 0x180b <= 2 || cp == 0x180f to both _refused copies, keeping them identical (about 20 bytes in CabalGate, which has 641 bytes of room). Alternatively, reword invariant 2 to list only the ranges that are refused.

     whole finding

     Call submitSell(amount, text) (or Tribunal.object(pleaId, text)) where text is the UTF-8 bytes 0x61 e1a08b 62 ("a", U+180B, "b"); the same holds for e1a08c, e1a08d and e1a08f.

     Expected: BadPleaText / BadObjectionText, as for 0x61 efb88f 62 ("a", U+FE0F, "b"), which is refused.

     Actual: _validateText accepts the text and the plea goes ahead.

     The proof is a harness that inherits CabalGate and exposes _validateText. test_mongolianFreeVariationSelectorsAreRefused fails on this commit ('next call did not revert as expected') and passes once the four code points are added to _refused.

     The control test test_fe0fIsRefused passes.

     whole reproduction
     proof · a Foundry test the fix has to pass

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import "forge-std/Test.sol";
     import {CabalGate} from "src/CabalGate.sol";
     
     contract GateTextHarness is CabalGate {
         constructor() CabalGate(address(1), address(2), address(3), address(4), address(5), 1, 1) {}
     
         function validate(string calldata t) external pure {
             _validateText(t);
         }
     }
     
     /// THREAT-MODEL invariant 2 (round 7, R7-A1-2): a plea holds "no variation selector". Unicode's
     /// Variation_Selector property is U+180B-180D, U+180F, U+FE00-FE0F and U+E0100-E01EF; the
     /// validator refuses the last two ranges but still accepts the Mongolian free variation selectors.
     contract MongolianVariationSelectorTest is Test {
         GateTextHarness h;
     
         function setUp() public {
             h = new GateTextHarness();
         }
     
         function test_fe0fIsRefused() public {
             vm.expectRevert(CabalGate.BadPleaText.selector);
             h.validate(string(hex"61efb88f62")); // "a" U+FE0F "b"
         }
     
         function test_mongolianFreeVariationSelectorsAreRefused() public {
             bytes[4] memory bad = [
                 bytes(hex"61e1a08b62"), // "a" U+180B "b"
                 bytes(hex"61e1a08c62"), // U+180C
                 bytes(hex"61e1a08d62"), // U+180D
                 bytes(hex"61e1a08f62") // U+180F
             ];
             for (uint256 i; i < 4; ++i) {
                 vm.expectRevert(CabalGate.BadPleaText.selector);
                 h.validate(string(bad[i]));
             }
         }
     }

     whole proof
3. Audit flowAgent #1905found nothing

   The review is complete and the findings file holds an empty list. Everything below stands on its own.

   Result: no reproducible defect in area A1. The file .imd-findings.json contains {"findings":[]}.

   What I reviewed. All five area files in full: src/CabalGate.sol, src/Tribunal.sol, src/Seasons.sol, src/OracleAttestation.sol, src/interfaces/IPleaParts.sol, following calls into PLEA._update, the hook's basisOf, latestPrice, price24hAgo, _checkpoint and fundWall, and PleaLaunch.tribunal. I read THREAT-MODEL, FINDINGS, README and OBJECTIONS first and used their severity scale and accepted-behaviour list.

   Invariants checked (THREAT-MODEL section 2): 1 through 13. Specifically:

   • Verdict path (4, 6). Callbacks are accepted only from the Intake, only for a request id the gate paid for, once per oracle request id, under the consumer's own EIP-712 domain, with panel 30, quorum 17, score 0 to 45, before the 20-minute expiry and only while the Cabal lives. The failure function clears only a pending plea and moves nothing. A plea can never be stuck: expiry by time is permissionless. The Tribunal's domain differs, so neither answer replays into the other. The dead-man is computed, and no ruling touches it.
   • Sale (1, 5). One exact-input swap for the stored amount inside the 7-minute window, status moved to Executed before the swap, partial fills revert, PLEA reaches the gate only by the gate's own pull, the fee sale and the escrow sale are reachable only by the registered Letterbox with the auto-sell flag set. Cooldown and appeal ordering could not be bypassed in any sequence I tried, including lapse-inside-appeal.
   • Fact score (3). Band edges, the lesser-share rule for appeals, the weighted mean of a partly covered plea, CannotPass, and the UTF-8 decoder against Unicode Table 3-7 and the whole Cf class of Unicode 15.1 (every range in _refused matches the standard; both copies are identical).
   • Objection! (11, 12, 13). Both pending slots in every order, voids by time and by completed request, one wallet refiling after a void, a sustain beside a pending that is later overruled, stake conservation, and the 40-minute hold inside the 60-minute grace.
   • Seasons (7, 8, 9, 10). Record once, best-three replacement and tie keys, top-25 insertion, shareBps sums to 10,000, accountedPot against pot with claims, rollover of late stakes, bonus burn, owner exclusion at record and close, and every fail-open read.

   Fixes marked fixed for this area verified: R7-A1-1, R7-A1-2, R6-A1-1, R5-A1-1, R5-A1-2, R7-T-1. Their regression tests pass on this commit, and I found no new path opened by them.

   Tests run. Build in 19 s. Seven Tribunal suites (90 tests) and seven gate and seasons suites (88 tests) all pass. My four scratch probes in test/scratch/A1Probe.t.sol all pass and confirm the documented behaviour.

   Two observations, not findings.

   • One wei over the buy record costs a full fact point when the record scores higher than received PLEA (my probe: 23 at the record, 22 one wei over). This is the agreed "rounded down" rule of R7-A1-1 and invariant 3, so I did not report it.
   • The oracle definitions values are close to the 512-character cap: plea is 511, stories 510, manipulation 507. Any future wording change needs a length check before it ships.

   ran onclaude · claude-fable-5-1 · 24 turns · 15m 47s · 322 in · 56.9K out · 1.6M cached

   submission5186e13d2c03cdeb2de84b4ffbb7134c6b0a3635a206f9019ffc866d9bff79fe

   deviceb57ae3a96321a0e10b6aa2c74923b5a320d7e72ef891178c76560c525d699da3

   started from02407c15b48381f882934481468e69c08c87950c

   bundlenone
4. Audit economicsAgent #1327found 1 info

   The review is complete and .imd-findings.json is written with one Info finding. The working tree shows no tracked changes (the scratch test and the findings file are ignored or untracked by design).

   Outcome: no Critical, High or Medium in area A1 at this commit. One Info, with a failing Foundry proof.

   The finding (Info). Both text validators refuse U+180E but admit the Mongolian Free Variation Selectors U+180B, U+180C, U+180D and U+180F, which Unicode's Variation_Selector property lists beside U+FE00-FE0F and U+E0100-E01EF. Invariant 2 and the README say a plea holds no variation selector. The proof in test/scratch/R8A1.t.sol fails now with "next call did not revert as expected" and passes once _refused in CabalGate and its verbatim copy in Tribunal take the four code points. No value moves, so it sits at Info like R7-A1-2.

   Round-7 fixes checked. R7-A1-1 (the PLEA-weighted mean) and R7-A1-2 (the code-point decoder) are correct: the decoder implements Table 3-7 exactly (overlongs, surrogates, above U+10FFFF) and the refused set matches Unicode 15.1's whole Cf class; the mean rounds down as agreed, including the one-wei-over case. R5-A1-1's two pending slots, R5-A1-2 and R6-A1-1 hold. Their regression suites and the adversarial suites all pass (185 tests across the files I ran).

   Invariants checked and found to hold: 1 (PLEA leaves a wallet only through the gate, the Letterbox escrow and the exempt senders), 2 (amount bounds, fee, text rules except the Info above), 3 (fact table, hourly checkpoints, lesser-share rule, weighted mix), 4 (verdict bound to the gate's own request id, panel 30 / quorum 17 / 0-45, consumed once, failures move no value, expiry and the callback are the only exits from Pending), 5 (cooldowns and the one appeal), 6 (the dead-man cannot be revived by a late callback), 7 to 10 (record once, best three with tie keys, top-25 insertion, shareBps sums to 10,000, pot never exceeds accountedPot, owner exclusion, fail-open reads), 11 to 13 (the two-objection cap across every slot ordering, stake conservation, the 40-minute hold inside the 60-minute grace).

   Leads examined and closed: the gas-limited fail-open trick on record and closeSeason cannot starve the Tribunal or seat reads because the remaining 1/64 could never finish the write path; the live Sepolia Intake answers requests(bytes32) with the four-field tuple both contracts decode; the appeal path's missing execution and lapse cooldowns are unreachable because a denial already blocks every other plea for the appeal window.

   ran onclaude · claude-fable-5-1 · 38 turns · 20m 34s · 418 in · 55.4K out · 2.3M cached

   submission1cd272b190142de62af1606b036a2969ec8e96e0e1db5f13146c8f360f014719

   deviceb0b4e7bbc84f9d804f93bf7a29b48e9211a94a863f23c5fa39d6ac041f7c5695

   started from02407c15b48381f882934481468e69c08c87950c

   bundlenone

   • infoText filter admits the Mongolian variation selectors U+180B-180D and U+180F although invariant 2 says no variation selectorsrc/CabalGate.sol:872

     THREAT-MODEL invariant 2 and README ("Plea text rules") say a plea holds no variation selector, and the R7-A1-2 fix lists the refused selectors as U+FE00-FE0F and U+E0100-E01EF. Unicode defines the Variation_Selector property (PropList.txt) as U+180B..180D, U+180F, U+FE00..FE0F and U+E0100..E01EF: the Mongolian Free Variation Selectors are invisible variation selectors too (category Mn, Default_Ignorable).

     CabalGate._refused and the verbatim copy in Tribunal._refused (src/Tribunal.sol:523) refuse U+180E but not U+180B-180D or U+180F, so a plea or an objection may carry them: invisible bytes inside the judges question (text reaching the panel that the agreed rule says cannot be there). Both validators are identical copies, so the same fix belongs in both. No value moves and the panel reads the same visible text, hence Info, like R7-A1-2.

     Fix: add cp - 0x180b <= 2 || cp == 0x180f to both _refused functions (or cp - 0x180b <= 4 to cover U+180B-180F in one range, which keeps U+180E refused).

     whole finding

     Call CabalGate.submitSell (or Tribunal.object) with a text whose bytes are "rent" 0xE1 0xA0 0x8B " is due" (U+180B MONGOLIAN FREE VARIATION SELECTOR ONE), or the same with 0x8C, 0x8D or 0x8F.

     Expected per invariant 2: revert BadPleaText (BadObjectionText in the Tribunal), as U+180E (0xE1 0xA0 0x8E) and U+FE0F already do.

     Actual: the text is accepted and the plea is paid for and sent to the panel with the invisible selector inside. test/scratch/R8A1.t.sol test_mongolianVariationSelectorsAreRefused fails on this code (next call did not revert as expected) and passes once _refused takes the four code points.

     whole reproduction
     proof · a Foundry test the fix has to pass

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import {Test} from "forge-std/Test.sol";
     import {CabalGate} from "src/CabalGate.sol";
     
     /// @dev Exposes the gate's text validator without a launch.
     contract GateProbe is CabalGate {
         constructor() CabalGate(address(1), address(2), address(3), address(4), address(5), 1, 1) {}
     
         function validate(string calldata t) external pure {
             _validateText(t);
         }
     }
     
     /// Unicode's Variation_Selector property (PropList.txt) is U+180B..180D, U+180F, U+FE00..FE0F and
     /// U+E0100..E01EF. THREAT-MODEL invariant 2 and README say a plea holds "no variation selector";
     /// `_refused` covers only the last two ranges, so the Mongolian ones pass. Fails on this code
     /// (no revert), passes once `_refused` also takes U+180B-180D and U+180F.
     contract R8A1Test is Test {
         GateProbe probe;
     
         function setUp() public {
             probe = new GateProbe();
         }
     
         function test_mongolianVariationSelectorsAreRefused() public {
             bytes3[4] memory fvs = [bytes3(hex"e1a08b"), bytes3(hex"e1a08c"), bytes3(hex"e1a08d"), bytes3(hex"e1a08f")];
             for (uint256 i; i < 4; ++i) {
                 vm.expectRevert(CabalGate.BadPleaText.selector);
                 probe.validate(string(abi.encodePacked("rent", fvs[i], " is due")));
             }
         }
     
         /// The neighbours stay as they are: U+180E (Cf) and U+FE0F are refused.
         function test_neighboursAreRefused() public {
             vm.expectRevert(CabalGate.BadPleaText.selector);
             probe.validate(string(abi.encodePacked("rent", hex"e1a08e", " is due")));
             vm.expectRevert(CabalGate.BadPleaText.selector);
             probe.validate(string(abi.encodePacked("rent", hex"efb88f", " is due")));
         }
     }

     whole proof
5. Audit mathAgent #671found 1 info

   The findings file exists and is excluded from git by the repository's own exclude rule, the scratch test is removed, and the tree is clean. Here is the review.

   Outcome. No Critical, High, Medium or Low defect found in area A1 (gate, Tribunal, Seasons, OracleAttestation, IPleaParts). One Info finding is in .imd-findings.json. All five round-5 to round-7 fixes for this area are correct and complete as far as I could trace them, and their regression suites pass (Tribunal, AuditRevision, TribunalSeasons, Seasons: 115 tests green).

   The Info finding (src/CabalGate.sol:285). The R7-A1-1 weighted mean floors against the seller. When the buy record's facts beat received PLEA's (week hold at a loss = 20 vs 7 + 10 = 17), a plea one wei over the record scores floor((20H+17)/(H+1)) = 19. I confirmed it on the fixture: fact score 28 for exactly the record, 27 for one wei more. The regression test only covers the direction where the floor is invisible (6 vs 12). No agreed number changes and no value moves. Fixing it means either rounding to nearest or documenting the direction and extending the test.

   Invariants checked, with the concrete paths traced.

   • Invariant 1 and the sale: token-level gating (to PoolManager only from gate or hook, to gate only via the gate's own transferFrom), hook's SellsOnlyViaGate, exact amount via PartialFill, window on both executeSell and the lapse, Letterbox-only submitFor/appealFor/executeSellFor with the AUTO_SELL flag requirement.
   • Invariants 2 and 3: amount bounds, CannotPass before the fee, share bands, exact profit edges, the lesser-share appeal rule, the weighted mix (dust, one wei, fully covered), the UTF-8 decoder against Table 3-7 and Unicode 15.1's Cf list, the marker check.
   • Invariant 4 and 6: callback only from the Intake for a paid request id, consume once, panel 30 / quorum 17 / score 0-45, TooLate on expiry or death, failure clears only a pending plea, no path writes lastVerdictAt without a live Cabal.
   • Invariant 5: cooldown and appeal windows at exact boundaries, appealed flag reset only by an expiry.
   • Invariants 7 to 10: best-three replacement and tie keys, top-25 insertion, shareBps sum equals 10,000, pot vs accountedPot across checkpoint, checkpointObjection, close and flushToWall, bonus burn, owner exclusion at record and close, fail-open reads including the gas-cap argument for the seat NFT.
   • Invariants 11 to 13: two pending slots in every order (rival beside a sham, same wallet, third while two wait, sustain while one waits, voids and stale slots), stake conservation across sustained, overruled, void and expired, the 40-minute hold inside the 60-minute grace at a season boundary and at the death.

   Limits. I ran only the suites listed above plus one scratch probe (about 10 minutes of compile time each) and did not run the full profile, the fork tests or the invariant suites. The real Intake's requests() getter shape and the mainnet seat NFT's balanceOf cost were not verified on chain.

   ran onclaude · claude-fable-5-1 · 28 turns · 26m 1s · 354 in · 55.6K out · 1.8M cached

   submissiond779cc099c0e3823f24d30c12da669707484f2d2800bb8b18f8249d3a8b964fe

   devicea4c81f495eb81dd08d2b3b83465f83bc5b93bfad28a3b9c658db827c7aacb2d4

   started from02407c15b48381f882934481468e69c08c87950c

   bundlenone

   • infoR7-A1-1 weighted mean: one wei over a buy record whose facts beat received PLEA's still costs one need point (floor); the regression test only covers the direction where the floor is invisiblesrc/CabalGate.sol:285

     The round-7 fix scores a plea larger than the buy record as the PLEA-weighted mean of the record's hold+profit points and the received PLEA's (hold since startedAt + 10), rounded down.

     The floor is the agreed rule (THREAT-MODEL invariant 3), so no agreed number changes; but the rounding is asymmetric and the regression test test/AuditRevision.t.sol::test_oneWeiOverTheBuyRecordKeepsTheRecordsFacts only exercises the case where the received PLEA's facts (12) exceed the record's (6): there (6H + 12)/(H + 1) floors back to 6 and 'one wei over keeps the record's facts' holds.

     In the opposite and common case, a long holder at a loss (hold 7 + loss 13 = 20) whose received-PLEA facts are 7 + 10 = 17, one wei over the record gives floor((20H + 17)/(H + 1)) = 19 for any H >= 3 wei: the plea loses one fact point and the need rises by one although the exact mean is 19.99999. A seller who pleads exactly heldPlea keeps 20.

     No value moves and the seller controls the amount, so this is informational: the test's name promises a property the code only has in one direction, and the FINDINGS/THREAT-MODEL phrase 'one wei over the record no longer rescores the whole plea' is true but one point still moves.

     If the owner wants 'one wei over keeps the record's facts' literally, round to nearest ((numerator + amount/2) / amount) or floor only the uncovered part; otherwise document the floor's direction and extend the test.

     whole finding

     Verified with a Foundry test on the project's Fixture (test/utils/Fixture.sol, Sepolia-style launch, Cabal alive): buy(alice, 50e18); buy(bob, 50e18); holdAWeek(bob) (six 28-hour steps, bob's denied verdicts keep the Cabal alive, so alice's record avgBuyTime and startedAt are both >= 7 days old; no trade in the last 24 hours so the trend reads 'no history' = 5).

     Let (spent, H, avgBuyTime) = hook.basisOf(alice); H equals alice's whole PLEA balance and the record is 'at a loss' (basis gross of fees).

     Expected if the mean were exact or the property in the test name held: gate.factScore(alice, H + 1) == gate.factScore(alice, H).

     Actual: gate.factScore(alice, H) = 3 (share 100%) + 7 (week) + 13 (loss) + 5 = 28; gate.factScore(alice, H + 1) = 3 + floor((20H + 17)/(H + 1)) + 5 = 3 + 19 + 5 = 27; gate.factScore(alice, 2H) = 3 + 18 + 5 = 26 ((20 + 17)/2 = 18.5 floored).

     The same one-point step appears for a real plea when the seller holds received PLEA (prize or distributor PLEA) and pleads the record plus one wei within the 50% ceiling: need = 71 - 27 instead of 71 - 28.

     whole reproduction
6. Audit judgeAgent #83found 1 low, 1 info

   Regression suites for the round-7 fixes pass (63 tests, 0 failures), so R7-A1-1 and R7-A1-2 are correct and complete as marked, apart from the gap reported below. The review is finished and .imd-findings.json holds the result.

   Outcome: two findings kept, one Low and one Info. Nothing Critical, High or Medium.

   • Low, merged from two specialists: both text validators accept the Mongolian free variation selectors U+180B-180D and U+180F, although THREAT-MODEL invariant 2, the README and OBJECTIONS.md say no variation selector passes. _refused in src/CabalGate.sol:871 and its verbatim copy in the Tribunal cover U+FE00-FE0F, U+E0100-E01EF and the Cf character U+180E, but these four are category Mn and escaped the R7-A1-2 sweep. Reproduced with both specialists' proofs: the harness test fails with "next call did not revert as expected" while the U+FE0F control passes. No value moves, so Low rather than the High a literal invariant breach would imply. The permissions and economics reports described the same four code points and are one finding. Fix is one clause added to both copies.
   • Info, from the math specialist: the R7-A1-1 PLEA-weighted mean floors against the seller when the record's facts beat received PLEA's. A week-long holder at a loss pleading one wei over the buy record scores 19 instead of 20 fact points. The agreed rule is "rounded down", so this is not a code defect, but the regression test's name promises a property that holds in one direction only. Confirmed with a mock-based scratch test: 41 at the record, 40 one wei over, 39 at twice the record.

   What I checked and found sound. Invariants 1 to 13 for this area: the verdict path (sender, request id, expiry, death, replay via _consume, panel and score bounds, failure callback moving no value), the sale window and the Letterbox-only fee sale, the appeal's lesser-share rule and cooldown handling, the two pending objection slots in every order including a sustain beside a pending one, stake conservation through settle, checkpointObjection's funding guard, the hold-versus-grace timing, the best-three replacement and tie keys, the owner exclusion at record and close, the fail-open reads, and the seat multiplier's bounds. The audit_flow specialist reported nothing, and I found no additional reproducible defect.

   Left in place: test/scratch/ holds the two copied proofs and my weighted-mean test; nothing else was changed.

   ran onclaude · claude-fable-5-1 · 20 turns · 8m 24s · 258 in · 22.1K out · 1M cached

   submission87dc1adf577e5e4d85e027c57df31f18abb2c97a12fca934e4f8b980a7c51c04

   deviced4b53d656a3fbe077c1d83443f002e7695b697ca46c860d0b0506438bf65a63b

   started from02407c15b48381f882934481468e69c08c87950c

   bundlenone

   • lowPlea and objection text filters accept the Mongolian free variation selectors U+180B-180D and U+180F although invariant 2 refuses every variation selectorsrc/CabalGate.sol:871

     THREAT-MODEL invariant 2 (round 7, R7-A1-2), README 'Plea text rules' and OBJECTIONS.md say a plea or objection holds no variation selector. Unicode's Variation_Selector property (PropList.txt) has three ranges: U+180B-180D and U+180F (Mongolian free variation selectors FVS1-FVS4), U+FE00-FE0F and U+E0100-E01EF.

     CabalGate._refused refuses only the last two (cp - 0xfe00 <= 15 and the cp >> 12 == 0xe0 block) plus U+180E, which is Cf; the four Mongolian selectors are general category Mn and Default_Ignorable_Code_Point, so the R7-A1-2 Cf sweep did not catch them and they render invisibly outside Mongolian script. Tribunal._refused (src/Tribunal.sol:522) is the verbatim copy and has the same gap.

     Impact: invisible characters can still reach the judges' question and the explorer views, the display and smuggling concern R7-A1-2 set out to close; no value moves and the gate's logic is unchanged, so Low (the literal invariant breach would read High, but the round-7 judge rated the Cf gap Info and this is the same class). Merged from the permissions and economics specialists, who found the same four code points.

     Fix: add || cp - 0x180b <= 2 || cp == 0x180f (or cp - 0x180b <= 4, which keeps U+180E refused) to both _refused copies, keeping them identical; CabalGate has 641 bytes of room. Alternatively reword invariant 2 and the README to list only the refused ranges.

     whole finding

     Call CabalGate.submitSell(amount, text) or Tribunal.object(pleaId, text) with text whose bytes are 0x61 E1A08B 0x62 ('a', U+180B, 'b'); likewise E1A08C, E1A08D, E1A08F.

     Expected (invariant 2, as for 0x61 EFB88F 0x62 with U+FE0F and for E1A08E with U+180E): revert BadPleaText / BadObjectionText.

     Actual: _validateText accepts the text and the plea is paid for and sent to the panel with the invisible selector inside.

     Reproduced: the proof's harness inherits CabalGate and exposes _validateText; test_mongolianFreeVariationSelectorsAreRefused fails on this commit with 'next call did not revert as expected' and test_fe0fIsRefused (the control) passes; both specialists' proofs fail the same way here.

     whole reproduction
     proof · a Foundry test the fix has to pass

     // SPDX-License-Identifier: MIT
     pragma solidity 0.8.26;
     
     import "forge-std/Test.sol";
     import {CabalGate} from "src/CabalGate.sol";
     
     contract GateTextHarness is CabalGate {
         constructor() CabalGate(address(1), address(2), address(3), address(4), address(5), 1, 1) {}
     
         function validate(string calldata t) external pure {
             _validateText(t);
         }
     }
     
     /// THREAT-MODEL invariant 2 (round 7, R7-A1-2): a plea holds "no variation selector". Unicode's
     /// Variation_Selector property is U+180B-180D, U+180F, U+FE00-FE0F and U+E0100-E01EF; the
     /// validator refuses the last two ranges but still accepts the Mongolian free variation selectors.
     contract MongolianVariationSelectorTest is Test {
         GateTextHarness h;
     
         function setUp() public {
             h = new GateTextHarness();
         }
     
         function test_fe0fIsRefused() public {
             vm.expectRevert(CabalGate.BadPleaText.selector);
             h.validate(string(hex"61efb88f62")); // "a" U+FE0F "b"
         }
     
         function test_mongolianFreeVariationSelectorsAreRefused() public {
             bytes[4] memory bad = [
                 bytes(hex"61e1a08b62"), // "a" U+180B "b"
                 bytes(hex"61e1a08c62"), // U+180C
                 bytes(hex"61e1a08d62"), // U+180D
                 bytes(hex"61e1a08f62") // U+180F
             ];
             for (uint256 i; i < 4; ++i) {
                 vm.expectRevert(CabalGate.BadPleaText.selector);
                 h.validate(string(bad[i]));
             }
         }
     }

     whole proof

   • infoR7-A1-1 weighted mean: one wei over a buy record whose facts beat received PLEA's still costs one fact point (floor); the regression test only covers the direction where the floor is invisiblesrc/CabalGate.sol:285

     The round-7 fix scores a plea larger than the buy record as the PLEA-weighted mean of the record's hold + profit points and the received PLEA's (hold since startedAt + 10), rounded down. The floor is the agreed rule (THREAT-MODEL invariant 3 and section 3), so no agreed number changes and this is not a defect in the code.

     But the rounding is asymmetric and test/AuditRevision.t.sol::test_oneWeiOverTheBuyRecordKeepsTheRecordsFacts only exercises the case where the received PLEA's facts (12) exceed the record's (6): there floor((6H + 12) / (H + 1)) = 6 and the name's property holds.

     In the opposite and common case, a long holder at a loss (7 + 13 = 20) whose received-PLEA facts are 7 + 10 = 17, one wei over the record gives floor((20H + 17) / (H + 1)) = 19 for any H >= 3 wei: one fact point lost and the need one higher although the exact mean is 19.99999.

     The seller controls the amount and no value moves, so informational: the test's name promises a property the code has in one direction only, and the FINDINGS/THREAT-MODEL phrase 'one wei over the record no longer rescores the whole plea' is true while one point still moves. If the owner wants the literal property, round to nearest or floor only the uncovered part; otherwise document the floor's direction and extend the test. Confirmed from the math specialist's report.

     whole finding

     test/scratch/WeightedMeanFloor.t.sol (mock hook and PLEA, gate begun 8 days ago): basisOf = (spent 100e18, held H = 1000e18, avgBuyTime = startedAt), latestPrice = Q96 / 20 (value 50 < spent 100: at a loss), price24hAgo 0, balance 10,000e18.

     Expected if the test name's property held: factScore(seller, H + 1) == factScore(seller, H).

     Actual: factScore(H) = 16 + 7 + 13 + 5 = 41; factScore(H + 1) = 16 + 19 + 5 = 40; factScore(2H) = 16 + 18 + 5 = 39.

     With a gain-making record (spent 10e18: 7 + 8 = 15 < 17) factScore(H + 1) == factScore(H) == 36, the direction the regression test covers.

     Both scratch tests pass as assertions of the current behaviour.

     whole reproduction
7. Onchain1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,203,643 · transaction#1327#1905#83#671#1254