Art 780 Solana PDA Bump and ATA Audit

A program-derived address is nothing more than SHA-256 over the seeds, the bump byte, the program id and the marker string ProgramDerivedAddress.

Pinned at solana-labs/solana commit 7700cb3128c1f19820de67b81aa45d18f73d2ac0, sdk/program/src/pubkey.rs, create_program_address L585-616: the client function hashes every seed in order, then the program id, then the 21 marker bytes, and refuses the result when it decompresses to an Ed25519 curve point. The successor SDK (anza-xyz/solana-sdk commit 021fd2f1864ab194b53498bb03c21ad1dc124b8d, address/src/derive.rs) keeps the identical recipe. The first fixture anchors this node on addresses the pinned test suite itself publishes: seeds [empty] with bump 1 under the upgradeable loader program yield BwqrghZA2htAcqq8dzP1WDAhTXYTYWj7CHxF5j7TDBAe, and the kernel reproduces that byte for byte.

Run the AINumbers MCP tool `audit_solana_pda_ata` with program_id "BPFLoaderUpgradeab1e11111111111111111111111", seeds [{"data":"","encoding":"utf8"}], bump 1 and claimed_address "BwqrghZA2htAcqq8dzP1WDAhTXYTYWj7CHxF5j7TDBAe": the published golden address should come back as derived_hash_base58 with claimed_matches true.

find_program_address tries candidate bumps 255, 254, 253 and so on down to 1, and the first hash that lands off the curve wins.

That search order is pinned twice: try_find_program_address in the archived solana-program source starts at 255 and runs exactly 255 iterations, and the successor SDK precomputes the same 255-entry bump table. A claimed bump of 0 can still recompute to a matching address (the pinned test suite publishes one: the sun-sign seed at bump 0 yields 13yWmRpaTR4r5nAktwLqMpRNr28tnVUZw26rTvPSSB19), but it is never canonical. The staged gloss that said the scan runs 255 to 0 is corrected here against the primary text; the kernel states which rule it implements in every output note.

Same tool, seeds [{"data":"","encoding":"utf8"}] with bump 253: claimed_bump_is_canonical comes back true, and canonical_address reads DNKLRoKoM7XxX2iW1PTnqo6iP6CPpVDBgeN9hrpu2R2R, the first off-curve hit below the two on-curve candidates 255 and 254.

A non-canonical bump that also lands off-curve gives the same seeds a second, different, perfectly valid PDA. That is the substitution class.

Fixture F5 pins this pair with real numbers: under the upgradeable loader program, seeds ["vault"] at bump 254 yield HbSEsJZ7N5uN1mEBaVuFVMXDARHcq4e4AmPoWDQbgrzq and at bump 252 yield 5mKEiyoA669YYj7QRCfcBdZAnX2r38ZnXKpmk3rFNuFv. Both decompress off the curve, so both are valid PDAs. A tool that only derives with a stored bump stays silent about the other one; this node reports claimed_bump_is_canonical false and keeps both addresses visible as facts. No wording about attackers or intent: the booleans are the finding.

Run the tool twice with seeds [{"data":"vault","encoding":"utf8"}], once with bump 254 and once with bump 252, claimed_address set to the matching address each time: both runs return claimed_matches true, only the first returns claimed_bump_is_canonical true.

When the 32 hash bytes decompress to an Ed25519 curve point, create_program_address refuses them outright. The audit reports that as the on_curve fact.

Fixture F6 is a real case found by search: for seeds ["oc0"] at bump 255 the hash itself is a curve point, so no program can ever own that address as a PDA. The output says on_curve true, create_program_address_verdict on_curve, and still shows the canonical bump 254 with its own address, so a reader sees both facts at once: the claimed tuple recomputes to the claimed string, and that string is unusable as a PDA. The off-curve test is the vendored noble Ed25519 point decompression, the same primitive the estate already uses for signature verification nodes.

Run the tool with seeds [{"data":"oc0","encoding":"utf8"}], bump 255, claimed_address "36ETbDqxX3nXTJSj4MNThicebuuRLsRs58oGudAke7ei": claimed_matches true, on_curve true, canonical_bump 254, and the flags CLAIMED_BUMP_ON_CURVE and NON_CANONICAL_BUMP_CLAIMED together.

An associated token account is a PDA with seeds [wallet, token program id, mint] under the ATA program. Put the classic Token program in those seeds for a Token-2022 mint and you derive a different account.

The pinned ATA source (solana-program/associated-token-account at 4004274dfb861e09570af873b46cb0b0919e8df0, interface/src/address.rs) states the seed order and, in its own deprecation note, that the classic-only helper "assumes the SPL Token program, which does not work for Token-2022 mints". Free SDK helpers still ship that assumption. Paste wallet, mint and the mint's real token program and the node returns both derivations with their bumps; the mismatch boolean is true exactly when the mint is declared under Token-2022 (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb, pinned in spl-token-2022-interface 3.1.2) and the two addresses differ. Facts only: both addresses are stated, neither is called wrong.

Run the tool with wallet, mint and token_program_id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb: the ata_derivation block returns both addresses (Gdjpegrt... under the declared program, FGETo8T8... under the classic one), both at canonical bump 254, with token_program_mismatch true.

One input surface, one output contract, one kernel digest, and the whole thing runs offline.

Kernel: chaingraph/kernels/art-780-solana-pda-ata-audit.kernel.mjs: byte concatenation, vendored SHA-256, vendored Ed25519 point decompression and base58 over pasted values; a fixed 255-iteration bump scan whose bound never comes from the inputs; no network, no storage, no RPC. Provenance: solana-labs/solana at commit 7700cb3128c1f19820de67b81aa45d18f73d2ac0 (sdk/program/src/pubkey.rs, create_program_address and try_find_program_address, with the published test vectors as golden fixtures), cross-checked against anza-xyz/solana-sdk commit 021fd2f1864ab194b53498bb03c21ad1dc124b8d (address/src/derive.rs); the ATA program source at solana-program/associated-token-account commit 4004274dfb861e09570af873b46cb0b0919e8df0; the Token-2022 program id pinned in spl-token-2022-interface 3.1.2. Limits follow the primary text: at most 16 seeds counting the bump, each seed at most 32 bytes, reported as facts rather than silently dropped. Prove status: deferred for this new node, picked up by the next proving batch; the property floor already runs an independent reimplementation (a separate SHA-256 and a separately written curve test) against every fixture.

Run the AINumbers MCP tool `audit_solana_pda_ata`. Task: audit a claimed program-derived-address tuple (program id, seeds, bump, claimed address) for canonical-bump correctness and address substitution, and optionally derive the associated token account under a declared token program side by side with the classic Token program for Token-2022 mints.