fix: validate mainnet_ca from Supabase against on-chain SPL Token mint ownership

[Ayomisco]

Closes #356

What

Add a getMultipleAccountsInfo ownership check in crank.ts before storing mainnet_ca addresses in the override mints table.

Why

The previous code accepted any string that passed the base58 regex. There was no on-chain check that the address is owned by the SPL Token program. A pubkey owned by any other program would pass the regex and be stored, causing the keeper to send crank transactions against it.

Changes

• src/services/crank.ts (lines 1193-1210): after the base58 filter, batch-fetch getMultipleAccountsInfo for all candidates. Keep only addresses whose account owner matches TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA. On any RPC error, discard all overrides for the cycle (fail closed).

[coderabbitai]

Warning

Review limit reached

@Ayomisco, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 55 minutes and 49 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: f0b1be77-c248-4e1a-964a-4bd8b0a3305c

📥 Commits

Reviewing files that changed from the base of the PR and between 8ee810d and ee22309.

📒 Files selected for processing (1)

• src/services/crank.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[dcccrypto]

Independent verification — not an approval (QA/Security own that). The guard is sound, but this turns one existing test red. I found the cause and verified a one-line fix.

The breakage

main  → tests/services/crank.test.ts   41 passed, 8 skipped   (all green)
#357  → tests/services/crank.test.ts    1 FAILED
  × retries v17 keeper portfolio provisioning on normal rediscovery when keeperPortfolio is null
    AssertionError: expected "vi.fn()" to be called 1 times, but got 2 times   (crank.test.ts:406)

The assertion is expect(shared.getConnection).toHaveBeenCalledTimes(1).

Cause

getConnection() is acquired unconditionally at crank.ts:1199, before the candidate loop — so it runs on every discovery even when no row has a mainnet_ca to validate. The connection is only actually used inside if (candidates.length > 0) at :1215.

One-line fix, verified

Move the acquisition inside the guard that uses it:

const SPL_TOKEN_PROGRAM = "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA";
-const conn = getConnection();

 if (candidates.length > 0) {
+  const conn = getConnection();
   try {

I applied exactly that on your branch and re-ran:

41 passed, 8 skipped   ← green again

It also happens to be better behaviour on its own merits: no connection acquired on discovery cycles that have nothing to validate.

One caveat on attribution: running that test with -t in isolation fails on main too — it depends on state from earlier tests in the file. So I used the full file as the baseline, which is green on main. The breakage is genuinely from this PR, not pre-existing.

On the guard itself

The validation logic looks right to me:

• base58 shape check before constructing a PublicKey, so a malformed row can't throw
• batched getMultipleAccountsInfo rather than N round-trips
• fails closed — !info || owner !== SPL_TOKEN_PROGRAM sets {}, so an unverifiable mainnet_ca is dropped rather than trusted. That's the right direction for KEEPER-9, where the whole risk is a poisoned Supabase row redirecting a price lookup.
• logs the offending slabAddress and actualOwner, which is what an operator needs

One gap

There is no test for the new validation. Once the above is fixed, the natural companions are: a row whose mainnet_ca is owned by a non-Token program is dropped, and a valid mint survives. Without them, a later refactor could remove the ownership check and the suite would stay green — the exact poisoning this PR exists to block.