Three false-positive patterns from running sentio on a mainnet ZK/privacy codebase (+ one true positive it caught)

[koshak01]

Thanks for sentio — ran 0.2.9 across the programs of an open-source Rust
privacy framework on Solana (Groth16 shielded pool + Token-2022 confidential
transfers, live on mainnet). It's a genuinely useful pre-audit pass. Sharing
three false-positive patterns from a ZK/privacy codebase that might help tuning,
plus one real finding it correctly caught.

First, the true positive, since credit is due: SW005 flagged a raw += / -=
on try_borrow_mut_lamports() in a withdraw path. That one was legitimate — we
switched it to checked_sub/checked_add. So the tool paid for itself. The rest
below are just tuning signal.

FP 1 — SW024 (division by zero) doesn't resolve compile-time consts

pub const ROOT_RING_SIZE: usize = 30;
// ...
pool.root_ring_head = (pool.root_ring_head + 1) % ROOT_RING_SIZE as u32;

SW024 flags % ROOT_RING_SIZE because the divisor is a non-literal, but it's a
module-level const that can never be zero. Resolving const values in scope
before flagging a non-literal divisor would remove this class of FP.

FP 2 — SW002 (missing owner check) on accounts secured by a ZK proof or used only as a seed

In privacy/ZK programs, some accounts are intentionally UncheckedAccount with
a documented /// CHECK: rationale, because their integrity comes from
somewhere the AST can't see:

/// CHECK: the recipient's pubkey is reduced mod the BN254 scalar field and
/// bound to the Groth16 proof as a public input, so a front-runner who swaps
/// this field invalidates the proof.
#[account(mut)]
pub recipient: UncheckedAccount<'info>,

Here an owner check would be meaningless — recipient is a payout target, and
front-run protection is the proof binding (Tornado-style). Same for a relayer
payout account, and for an account used only as a PDA seed (to_owner whose
value is validated by the derived PDA's bump).

Two ideas: (a) lower confidence / severity when an UncheckedAccount carries a
documented /// CHECK: comment, and (b) don't flag accounts that are only ever
used as a payout target or as a PDA seed input (never read as data). These are
the dominant SW002 FPs in ZK code.

FP 3 — SW027 (missing event) doesn't recognize msg! program logs

pub fn init_vault(ctx: Context<InitVault>) -> Result<()> {
    ctx.accounts.vault.bump = ctx.bumps.vault;
    msg!("conf-vault-init:{}", ctx.accounts.vault.key());  // <-- observability
    Ok(())
}

SW027 looks for Anchor emit! events, but a large share of Solana programs
(including much of SPL) expose state changes through structured msg! program
logs that off-chain indexers parse directly — no Anchor event involved. Treating
a msg! in the same handler as an observability sink would clear this FP.

Context

The codebase is public if a concrete repro helps:
https://github.com/koshak01/tidex6 — the findings above are in
programs/tidex6-verifier, programs/tidex6-wusdc-pool, and
programs/tidex6-confidential-amounts. Happy to provide anything useful.

Take or leave any of this — just wanted to give back after the tool caught a
real one for us.

[AtoMicKraK1n]

@koshak01 glad it helped, will look into it more!
Could you please add FP2 and FP3?

[koshak01]

Apologies — the body got truncated when I filed this: it cut off mid-code-block
in FP 1, so FP 2 and FP 3 never made it onto the page. That was on my side, not
something you missed.

I have edited the issue and the full text is there now:

• FP 2 — SW002 on UncheckedAccounts whose integrity comes from a Groth16
  public input (a swapped recipient invalidates the proof) or that are only
  ever used as a PDA seed. Suggestion: lower confidence when a documented
  /// CHECK: is present, and skip accounts that are never read as data.
• FP 3 — SW027 not recognising structured msg! program logs as an
  observability sink. Much of SPL exposes state changes that way rather than
  through Anchor emit!.

Both have the concrete code that triggered them. Happy to run a newer version
against the same programs if you want a before/after on any rule.

[AtoMicKraK1n]

Apologies — the body got truncated when I filed this: it cut off mid-code-block in FP 1, so FP 2 and FP 3 never made it onto the page. That was on my side, not something you missed.

I have edited the issue and the full text is there now:

• FP 2 — SW002 on UncheckedAccounts whose integrity comes from a Groth16
  public input (a swapped recipient invalidates the proof) or that are only
  ever used as a PDA seed. Suggestion: lower confidence when a documented
  /// CHECK: is present, and skip accounts that are never read as data.
• FP 3 — SW027 not recognising structured msg! program logs as an
  observability sink. Much of SPL exposes state changes that way rather than
  through Anchor emit!.

Both have the concrete code that triggered them. Happy to run a newer version against the same programs if you want a before/after on any rule.

thanks for the detailed analysis on FP so in the recent #2 PR FP1 is fixed and for the FP2 i agree, will treat it msg! as log sink and as FP3 is ZK based issue which we cant solve solely by AST so we maybe lower the check confidence and not auto skip! @koshak01

[AtoMicKraK1n]

Thanks again for the report — and for the SW005 true positive on the lamports path. That kind of feedback is exactly what we want.

Status

Item	Outcome
SW005 (lamports +=/-=)	True positive — glad it helped
FP1 — SW024 const divisor (ROOT_RING_SIZE as u32)	Fixed — non-zero const (incl. ca
FP3 — SW027 msg! logs	Fixed — msg! counts as an observability sink alongside `emit
FP2 — SW002 UncheckedAccount + ZK / seed / payout	Partially fixed — see below

FP2 (SW002) detail

We improved usage analysis so SW002 skips accounts that are only used as:

• .key() identity (including mut), and/or
• PDA seed input (seeds = […, field.key(), …])

We do not auto-silence based on /// CHECK: alone or on “integrity comes from a Groth16 public input.”

Why: Sentio is AST-only. We cannot see ZK proof binding, public inputs, or checks that only exist in another program. Treating those as safe without a visible on-chain constraint would hide real missing-owner bugs.

If integrity is intentionally proof-based or cross-program:

• document with /// CHECK:
• use // sentio-ignore SW002 or a baseline

Full write-up: docs/LIMITATIONS.md

Next

Ship the fixes in the next crates.io release (or install from main after merge). If you’re willing, a re-scan of tidex6 after that would be super helpful as a before/after.

Closing this as addressed for FP1/FP3 and the AST-visible part of FP2. Feel free to reopen or file a follow-up with a new snippet if something still looks wrong after the release.

@koshak01

[AtoMicKraK1n]

i have made a discord server for sentio would be glad if you joined! https://discord.gg/CE7AeMh7A

…

On Sun, 26 Jul 2026 at 2:22 AM, Koshak01 ***@***.***> wrote: *koshak01* left a comment (sentio-security/sentio-rs#1) <#1 (comment)> Apologies — the body got truncated when I filed this: it cut off mid-code-block in FP 1, so FP 2 and FP 3 never made it onto the page. That was on my side, not something you missed. I have edited the issue and the full text is there now: - *FP 2 — SW002* on UncheckedAccounts whose integrity comes from a Groth16 public input (a swapped recipient invalidates the proof) or that are only ever used as a PDA seed. Suggestion: lower confidence when a documented /// CHECK: is present, and skip accounts that are never read as data. - *FP 3 — SW027* not recognising structured msg! program logs as an observability sink. Much of SPL exposes state changes that way rather than through Anchor emit!. Both have the concrete code that triggered them. Happy to run a newer version against the same programs if you want a before/after on any rule. — Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=ATHHWIBRSH5VHVSP6FP2RX35GUMYNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBYGA2TGMBVGMY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5080530531>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATHHWIGOGNEVLOT6IHIRVT35GUMYNAVCNFSNUABGKJSXA33TNF2G64TZHMYTENBSGQZTMNBVGU5US43TOVSTWNBZG4YDANBSGA3TTILWAI> . You are receiving this because you commented.Message ID: ***@***.***>