Implemented imd-sdk with dependency-free Node 20 runtime, typed declarations, CLI, safety checks, static site warning banner, and GitHub-install prepare build.

Key files: README.md, client, typed API, CLI, and tests.

npm test passes: fixed independent viem signature vectors plus the full local mock quote → 402 → two signatures → submit → polling flow.

The audit is complete. Findings are in .imd-findings.json, no repository files were changed, and all scratch work lived in /tmp.

What I checked. I verified the SDK's keccak, secp256k1/RFC6979 signing and EIP-712 encoding against viem with the test vectors plus 20 random Permit2 messages. They match byte for byte. The canonical JSON function matches the one published in the IMD docs, the QuoteApproval types and field sources match the docs, the Permit2 types and nonce generation are correct, and the deadline is clamped to expiresAt minus 5 seconds. The live capabilities endpoint has the shape the term check expects. The defects are in constants, input validation and cap bookkeeping, not in the cryptography.

Findings, ranked:

1. Critical: wrong Permit2 address. The constant on src/index.js:8 has 39 hex characters (a dropped D). The in-house signer silently pads the truncated bytes and signs a malformed domain. Under the real Permit2 domain the signature recovers to a random address. A viem signer throws an invalid-address error instead. No real payment can ever succeed. The tests miss it because the vector test hard-codes the correct literal rather than importing the SDK constant, and the mock test never recovers the signature.
2. High: negative amounts bypass both caps. An amount string of -5 in capabilities, quote and challenge passes the comparisons and both cap checks, then the encoder two's-complements it. The resulting permit authorises 2^256-5 tokens, verified identical to viem's signature for that value. Any party holding the challenge can drain the full Permit2 allowance.
3. High: key leak on typo. A private key with one non-hex character makes BigInt throw a message containing the whole string, and the CLI prints that message to stderr. 63 of 64 nibbles leak.
4. Medium: per-day cap is process-local. Each CLI invocation starts at zero. Three consecutive imd pay --execute runs submitted 1.5 IMD against a 0.5 IMD daily cap. The CLI also has no way to set either cap.
5. Medium: cap is debited only after a successful submit. Two concurrent calls both pass the check and both sign. A 500 on the signed submit leaves the counter untouched, so the retry hands the server a second valid permit with a fresh nonce.
6. Low: original-quote cross-check is dead code. The documented quote response nests amount and payTo without a payment key, so the "differs from the original quote" branch never executes.
7. Low: the private key is an enumerable property. Logging or JSON-stringifying the client or signer prints it.

Next for the author: fix the constant and add a test that imports it and recovers the signature, validate amounts as positive canonical decimals before BigInt, validate key format before parsing, and reserve daily spend before signing with persistence for the CLI.

Fixed all seven findings and recorded the responses in .imd-responses.json. The daily spend ledger persists across CLI runs; reservations are serialized within a process.

npm run build passed. npm test passed the fixed signature vectors, but the local mock test failed because this environment could not connect to its loopback server. I also verified the Permit2 address is 40 hex characters and that invalid keys and signer inspection do not expose key material.

All seven earlier findings are fixed and I reproduced each fix. Four new, smaller defects are in .imd-findings.json. No repository file was changed; the findings file is git-excluded and is the only addition.

Earlier findings, settled as fixed

• PERMIT2 constant (critical). Now 40 hex chars. A real pay({execute:true}) against the mock produced a Permit2 signature that viem recovers to the signer's address under the canonical Permit2 domain, and the QuoteApproval signature recovers the same way. A viem account as signer also pays successfully.
• Negative amount (high). Amounts -5, +5, 0x10, 5.0, 1e18, 0 and 2^256 are all refused with 'invalid payment amount' before any signature.
• Key leaked via BigInt error (high). A mistyped key makes the CLI print only 'invalid private key'.
• Process-local daily cap (medium). Sequential CLI pays are refused after the first on the same day. Env caps exist.
• Reserve-after-sign (medium). A failed submit keeps the reservation and a retry is refused with one nonce issued. Concurrent in-process pays yield one payment and one refusal.
• Original-quote cross-check (low). The documented quote shape with differing amount or payee is now refused.
• Key in enumerable field (low). JSON.stringify and util.inspect show only the address.

New findings, ranked

1. Medium. The persisted ledger has no cross-process lock. Two simultaneous imd pay --execute processes both signed in 5 of 10 runs and the ledger then recorded only one payment. Anchored at src/index.js:61.
2. Medium. The tests debit the real daily ledger under the user's home. A second test run on the same UTC day fails with 'daily IMD spending cap exceeded', and real payments are blocked for the rest of that day. Anchored at test/paid-flow.test.mjs:53.
3. Low. Aborts before any signature exists, such as a quote expiring within 5 s or the signer rejecting, still consume the full daily cap.
4. Info. The new cap env vars and their wei units appear in neither --help nor the README, and a non-integer value surfaces as a raw BigInt error.

Each finding carries exact inputs, observed output and expected behaviour, and all snippets were verified to match the tree line for line.