Security checks

Checked on 17 October 2026, with one scanner re-check on 18 October 2026 (noted below). Everything below is a point-in-time check of the patterns and addresses named, run with my own scanner. It is not proof that nothing sensitive exists, and the programs are devnet and unaudited.

Key material in git history

• I scanned the full git history of 16 of my own repositories (14 pushed to my GitHub account, 2 local only) with keyscan.py. It validates base58 keypairs by deriving their public key, and also looks for key arrays, hex keys, private-key blocks, common token patterns and key-like file names.
• Result: 0 valid keypairs, 0 private-key blocks and 0 token-like strings in all 16.
• Re-run on 18 October 2026: keyscan.py --git over the full history of the Referee repository, including the four commits I pushed that day, found 0 valid keypairs, 0 key arrays, 0 hex keys, 0 private-key blocks and 0 token-like strings. GitHub secret scanning and Gitleaks were not re-run, so their figures below are as of 17 October.
• In the Referee repository I also searched every commit for key-related keywords and file names. The only matches were documentation text and the scanner's own search patterns.
• As a second, independent check, GitHub secret scanning is on for four repositories: Referee, verifex-live, ishvir-hub and my profile repository. On 17 October 2026 each showed 0 open and 0 closed alerts. GitHub's scanner looks for known provider token formats and does not recognise Solana keypairs.
• As a third check, I ran Gitleaks v8.30.1, an independent open-source scanner, over the full history of 14 of my own repositories. 12 reported no leaks (one of them has no commits yet). Referee reported 10 matches and solana-fall-transfer-hook reported 1, and I reviewed each one. All 10 Referee matches are the same value: the public address of Referee's authority account (GE7FbxTFG1ExcvCCuqScLxto65uw5rHqQFpwrH3cDyew), assigned to a constant named EXPECTED_AUTH in ten places in the scripts' history. On devnet that account is owned by the System Program and holds 0.01190752 SOL, as stated below. The one transfer-hook match is an entry on line 10 of Anchor.toml, in the [programs.localnet] section, in the same format as that repository's own program ID. It has no account on devnet, and I treat it as a program ID, not a key. The Referee repository's .gitleaksignore lists the ten reviewed matches. Move it aside and run gitleaks git to see them unfiltered.

Authorship

• Every commit in the Referee repository is authored by my GitHub account, and its contributors graph lists one contributor. How I use AI is on How I build.

Wallets

• Signing keys are local keypair files outside the repositories. No keypair file is tracked in any of the 16.
• The 56 devnet receipts for Referee were signed by 14 distinct addresses, three of which are program addresses. I checked all 14 on mainnet and each holds 0 SOL.

Receipts against the chain

• The on-chain ledger of calls to the Referee program holds 43 transactions. 37 are receipts in RECEIPTS.md and 6 are successful calls listed only on the replay page (5 register-trade calls and 1 early call I did not decode). The replay page lists 62 signatures in total.
• The other 19 receipts are transactions that do not call Referee: program deployments, direct DvP trades and the TrustRail Core steps.

Program funds and upgrades

• Referee's authority address (a program-derived address) held 0.01190752 SOL on devnet when I checked. None of the program's seven instructions withdraws it. The only transfer out is the rent refund during settle.
• Referee, Verifex and TrustRail Core are upgradeable by my wallet. That is a trust assumption. Referee has had seven in-place upgrades, five of them listed in its receipts.
• On 18 October 2026 I found four issues in Referee during my own code review and fixed them in two upgrades, each tested on devnet. What I did not fix is listed in the same log: docs/FIXES-18-OCT.md.
• Verifex's base path does not bind the presented agent program to the credential's subject, and its credentials last seven days and cannot be renewed by Verifex.

What this does not show

• It covers only the patterns, repositories and addresses named above, on the date above.
• The keypair checks were run with my own scanner. GitHub secret scanning and Gitleaks are independent of it, but they look for known token formats and generic key-like strings.
• No audit has been done on Referee, Verifex or TrustRail Core. Cantina reviewed the Solana Foundation's DvP program in May 2026; that review did not cover these programs.

Why I check this way

My background is in accounting and finance. I wrote my Honours thesis on post-project appraisals, and I was trained to assess the risk of material misstatement. This page is that habit applied to my own code: state the claim, state what was tested, and state what was not.

Repeat it

Clone the Referee repository and run python3 scripts/keyscan.py --git from its root. For the wallets, read the signatures in docs/RECEIPTS.md, fetch each transaction from a Solana RPC, list its signers, and check their mainnet balances.

How I build · Back to ishvir.xyz