I’d been treating smart-contract audits as the finish line for TermMax security. That was too neat.
A clean contract doesn’t help if the page in front of it swaps the contract address or changes transaction parameters before I sign. The last meter between the app and my wallet is part of the protocol too.
TermMax’s security docs say every frontend release gets a unique build SHA, the current SHA is shown in the app, and automated checks compare the deployed build with the expected one. Any drift is supposed to trigger an alert. They also describe container-image scanning and a restrictive Content Security Policy.
What made this feel less like a checklist is the timing. TermMax App V2 was added to the Immunefi scope on August 17. That scope explicitly treats malicious changes to a connected wallet’s transaction parameters, contract substitution, or malicious transaction submission as critical impacts.
I like this because it tests the thing users actually touch, not only the contracts behind it.
There’s still one question I’d ask. The docs say the authoritative SHA reference is maintained internally. A hash shown inside the app becomes much more useful if users can compare it with an independently published reference.
So my security check is now two lines: is the contract trusted, and is the interface serving the build I think it is?
@TermMax #TermMax
A clean contract doesn’t help if the page in front of it swaps the contract address or changes transaction parameters before I sign. The last meter between the app and my wallet is part of the protocol too.
TermMax’s security docs say every frontend release gets a unique build SHA, the current SHA is shown in the app, and automated checks compare the deployed build with the expected one. Any drift is supposed to trigger an alert. They also describe container-image scanning and a restrictive Content Security Policy.
What made this feel less like a checklist is the timing. TermMax App V2 was added to the Immunefi scope on August 17. That scope explicitly treats malicious changes to a connected wallet’s transaction parameters, contract substitution, or malicious transaction submission as critical impacts.
I like this because it tests the thing users actually touch, not only the contracts behind it.
There’s still one question I’d ask. The docs say the authoritative SHA reference is maintained internally. A hash shown inside the app becomes much more useful if users can compare it with an independently published reference.
So my security check is now two lines: is the contract trusted, and is the interface serving the build I think it is?
@TermMax #TermMax
