[maciejwitowski]

Adds an advisory CI check that looks for leaked EOA private keys in a pull request diff.

Why a regex does not work here

An Ethereum private key has no structure — 32 uniformly random bytes, no checksum, no version byte, no prefix. The only available pattern is (0x)?[0-9a-f]{64}, and in this repository that also matches transaction hashes, block hashes, every keccak digest, merkle and state roots, storage slots, ABI-encoded 32-byte words, and validator deposit_data fields. 32-byte hex is the native unit of this codebase.

This is why GitHub has no built-in detector for private keys, and why the off-the-shelf tools produce more noise than signal on a contracts repo.

What this does instead

Derive the address each candidate would control, then ask the chain whether that address has ever been used. A digest derives to an address with no nonce and no balance; a real key does not. Generic scanners cannot do this because they have no chain to ask — we do.

Measured over the tracked tree:

Stage	Count
64-hex candidates	5,782
Distinct values	588
Surviving the filters	2

Both survivors were triaged by hand; neither was a false positive.

The three rules that keep it quiet

Each is a statement about entropy rather than a denylist that has to be maintained:

1. Entropy bounds — a key must lie in [2^128, N). Anything smaller is an ABI-encoded integer (bytes32(1), a length prefix, an array offset), and those derive to the well-known "private key = N" accounts that have been used on every chain.
2. Public values — the EIP-1967 proxy slots and the Hardhat/Anvil development accounts are valid keys belonging to nobody, and being public they have genuine on-chain history. The implementation slot appears in every proxy deployment file we publish and those accounts appear in every fixture, so without this rule they alone produce hundreds of findings. All computed from their definitions, so the list cannot drift.
3. Breadth downgrade — a value in three or more files is a shared constant, not a leak. Breadth never opens a finding, only lowers the severity of one already raised.

Deliberate choices

• Advisory, not blocking. continue-on-error: true and no --fail-on-verified, so the real false-positive rate can be observed before anyone's merge depends on it. Promoting it later is a two-line change, documented in the README.
• Diff-scoped. Costs nothing, so the same check can be adopted on private repos where GitHub's paid secret scanning is not enabled.
• Fails loud, not quiet. A rate-limited or unreachable RPC is reported as incomplete rather than silently treated as clean.
• Never prints a key in full. Output is redacted to 0xabcdef…1234 plus the derived address — enough to locate the line without repeating the secret into CI logs.
• --ignore-scripts on install. A secret scanner is the last place to be running package postinstall hooks.
• Custom patterns were not an option. GitHub secret scanning custom patterns require Secret Protection on an org-owned repo, and would still be matching on shape.

Known blind spot

A freshly generated key that was never funded derives to an address with no history, so liveness will not see it. The optional known-address register and the secret-shaped-context check cover part of that tail, not all of it. This is a backstop — it does not replace keeping production keys somewhere they cannot be committed.

Verification

• 22 unit tests, no network and no chain required: npx mocha --require ts-node/register scripts/keyscan/scan.test.ts
• Both CI commands run end-to-end locally against this repo's dependency tree.
• Full-tree and diff modes exercised against Vana mainnet and Moksha.

🤖 Generated with Claude Code

[tnunamak]

Codex:

Thanks for adding a pre-push layer. Running before upload matters for public repositories, and the address and chain checks are useful as a second signal.

I reproduced four gaps that make this unsafe as the main enforcement path:

1. git diff base..local checks the endpoint diff, not every commit being uploaded. If commit A adds a key and commit B removes it, both commits are pushed but the endpoint diff is clean.
2. The zero-context diff cannot see an unchanged declaration near a new value. Adding a value below an existing privateKey declaration can produce no finding.
3. The pre-push hook invokes the scanner with --offline, so chain validation is disabled at the point where it could prevent public exposure.
4. CI is advisory: it uses continue-on-error and has no mode that fails on a verified result.

I would keep the semantic verifier as an advisory or scheduled second check. The shared scanner in vana-com/.github checks the complete pushed commit range in pre-push and CI. The draft integration for this repository is PR #70.

Making that CI check required still needs separate branch-protection approval because it changes merge behavior for everyone.

[tnunamak]

Follow-up: I adapted the scalar validation, address derivation, retry, and Vana/Moksha liveness work from this PR into the shared workflow. The draft is vana-com/.github #1, and the source attribution to you and this PR is retained in the code and NOTICE.

The central design keeps Gitleaks as the authoritative detector and runs liveness as a second, advisory job. Both jobs inspect every introduced commit through the same materializer and run only code from the caller's immutable central-workflow pin. RPC requests contain derived addresses, not private-key candidates.

The public draft callers are live and both scanner jobs pass:

• vana-smart-contracts #70
• vana-sdk #185
• vana #23

Your branch is unchanged. No branch-protection or ruleset settings were changed. Could you review the central draft? If the adapted version looks right, I suggest closing this PR in favor of the shared implementation after review.

[tnunamak]

Codex: Maciej, thanks again for this work. We used the address-derivation and Moksha/mainnet verification approach from this PR in the shared implementation:

vana-com/.github#1

The smart-contracts rollout is here:

#70

The shared version adds full commit-range scanning and an explicit pre-push setup command, keeps the hook offline after setup, and avoids changing core.hooksPath during package installation. On-chain verification is advisory, while the offline lexical scan remains the blocking control.

I’m closing this as superseded because merging both implementations would create competing hooks and policies. Your work directly informed the verification layer.