PRIVATE_KEY exposed in makefile and other sensitive data committed to the repository

The repository's Makefile and supporting build configuration include a PRIVATE_KEY environment value committed in plain text alongside other sensitive operational data. Anyone with access to the repository, including past contributors, forks, mirrors, or anyone who clones a snapshot before a force-push, can extract the key and derive the corresponding EVM address.

This is exacerbated by the fact that the same key was used during deployment and testing. Once a private key is committed to a public or shared repository, rotating it is the only safe response; deleting the commit does not invalidate the key because git history is preserved across forks and clones.

• Any account derived from the committed key is fully compromised.
• If that key is associated with any privileged role on a deployed contract (admin, executor, trader, oracle updater), the attacker inherits all the privileges of that role.
• If the key holds funds on any chain, those funds can be drained immediately.
• Even after key rotation, the previous key remains a forensic artifact and must be assumed to be in adversary hands.

• Rotate every key that was ever committed and revoke their access from every role and contract that referenced them.
• Move all secrets out of the repository: use a .env file that is git-ignored, a secrets manager, or per-developer keychains.
• Add a pre-commit hook (or CI check) that scans for high-entropy strings and known key formats to prevent recurrence.
• Audit the git history for any other accidental secret commits and rotate those credentials too.

D2: Fixed in 92e25b.

Cyfrin: Verified.