How to verify this audit

This page is the technical verification procedure for the audit at report.html. It exists so that any third party can independently reproduce the bytecodes, the fingerprints, and the Git authorship trail from public sources only.

1. The "signed checksum" is a Git commit

Rather than PGP, this report uses a signed Git commit on a public repository as its signed-checksum mechanism. The reasoning:

• Git commit hashes are SHA-1 / SHA-256 cryptographic digests of the exact file content plus the commit metadata (author, timestamp, parent). They are unforgeable without a SHA-1 preimage attack on the commit object.
• The commit is published in a public repository under a named GitHub account. Authorship of the commit is provably bound to that account, which in turn is bound to a person by GitHub's out-of-band identity verification.
• If the author used git commit -S with a GPG/SSH signing key, the signature is part of the commit object itself; git verify-commit <hash> validates it. The report also documents the reviewer’s name, organization, contact, and personal confirmation, so a third party can perform an out-of-band identity check on top of the cryptographic one.

To retrieve the signed checksum of report.html:

curl -sL https://api.github.com/repos/z.mohsin1/must-pirateship-audit/commits?path=report.html \
  | python3 -c 'import sys,json;d=json.load(sys.stdin);[print(c["sha"], c["commit"]["author"]["name"], c["commit"]["author"]["date"]) for c in d[:5]]'

The first commit listed is the one that introduced the report. Its SHA-1 is the signed checksum referenced in the report’s §8 Reviewer signature & verification.

2. Verify the source commit

The audited source is mustcompany/must-pirateship at commit 89018f0ee3b04538a7baab4cc58e7d03325bf7f4:

git clone https://github.com/mustcompany/must-pirateship.git
cd must-pirateship
git checkout 89018f0ee3b04538a7baab4cc58e7d03325bf7f4
git rev-parse HEAD
# expected: 89018f0ee3b04538a7baab4cc58e7d03325bf7f4
git log -1 --format='%H %ci %s'
# expected: 89018f0ee3b04538a7baab4cc58e7d03325bf7f4 2026-07-21 20:41:05 +0500 v0.3.0.3 fix: harden Polygon mainnet deployment handoff (#12)

Only one .sol file exists in the repository at this commit:

find . -name '*.sol'
# expected: ./contracts/RefundableProductEscrow.sol

3. Reproduce the bytecodes and fingerprints

You will need solc 0.8.30+commit.73712a01. On macOS (arm64 or x86_64), the official universal build is at binaries.soliditylang.org. Linux and other platforms: docs.soliditylang.org.

Save the standard-JSON input below to input.json:

{
  "language": "Solidity",
  "sources": {
    "contracts/RefundableProductEscrow.sol": { "content": "<paste verbatim source from must-pirateship@89018f0/contracts/RefundableProductEscrow.sol>" }
  },
  "settings": {
    "optimizer":  { "enabled": true, "runs": 200 },
    "evmVersion": "paris",
    "metadata":   { "bytecodeHash": "ipfs" },
    "outputSelection": { "*": { "*": [
      "evm.bytecode.object",
      "evm.deployedBytecode.object",
      "evm.bytecode.sourceMap",
      "evm.deployedBytecode.sourceMap",
      "metadata"
    ]}}
  }
}

Compile and re-derive the four SHA-256s:

solc --standard-json input.json > out.json

python3 - <<'PY'
import json, hashlib
from eth_abi import encode

o = json.load(open('out.json'))
ck = 'contracts/RefundableProductEscrow.sol'
c  = o['contracts'][ck]['RefundableProductEscrow']
bc = c['evm']['bytecode']['object']
dc = c['evm']['deployedBytecode']['object']
md = c['metadata']

beneficiary = '0xcF9178cA7360066B25de9c142A4c155abf151D6f'
min_pledge  = 300000000000000000000
args = encode(['address','uint256'], [beneficiary, min_pledge])
init = bc + args.hex()

print('creation sha256 :', hashlib.sha256(bc.encode()).hexdigest())
print('deployed sha256 :', hashlib.sha256(dc.encode()).hexdigest())
print('metadata  sha256 :', hashlib.sha256(md.encode()).hexdigest())
print('args     sha256 :', hashlib.sha256(args.hex().encode()).hexdigest())
print('initcode sha256 :', hashlib.sha256(init.encode()).hexdigest())
PY

Expected output:

creation sha256 : 9a2fdeedce6b4758e554a5c7a5e2978a8e74591ff5aedf93cbad1633d02b21ab
deployed sha256 : 9b9706867bfde369562f64c1c1d5779b8102c2484da3fd520e05ddf6472687e2
metadata  sha256 : b359e617193751c11ad8b29b2b9ba06cec9dd3fcdb868f183716d7960c66bb89
args     sha256 : c53eec263c48a81aca1999047e29c0c534d16bbf7f0ffcb3e080238e30142368
initcode sha256 : 33a7aae97e9b7a982c75dc4598469ac4e3ed9bffc8d182f1c1467e65bec55478

If any of these do not match, the report does not apply to the bytecode you are looking at. Do not deploy without investigating the mismatch.

4. Verify a deployed instance (if one exists on-chain)

Once the contract is deployed on Polygon PoS mainnet, any third party can verify the deployment by:

1. Fetching the deployment transaction input (tx.input) from a Polygon block explorer.
2. Stripping the last 64 bytes (constructor args) and verifying the leading 4992 bytes hash to 9a2fdeed….
3. Verifying the trailing 64 bytes hash to c53eec2… and ABI-decoding them to confirm the beneficiary and minimum pledge match the documented values.
4. Computing the runtime code hash from the deployed contract’s code and comparing it to 9b970686….

5. Verify the authorship

The named reviewer of record is Mohsin Zahid, with the public profile at linkedin.com/in/mohsin-zahid-dev. To verify the link between the report and the person:

• The report is hosted on a GitHub Pages site under the z.mohsin1 account, which corresponds to the public GitHub identity bound to the same person.
• The reviewing Git commit’s Author field is z.mohsin1 <z.mohsin1@users.noreply.github.com>; the Committer is the same.
• LinkedIn serves as the out-of-band identity proof: the report and the profile are cross-linked, and the profile’s About and activity confirm the same person authored the review.

This is a strictly weaker identity binding than a PGP signature tied to a long-term key, but it is the standard pattern for open-source audit reports and is sufficient for the threat model of a public Polygon deployment by a single product team. If a stronger binding is required, the reviewer can additionally sign the report file with a PGP key (instructions in §6 below).

6. Optional: add a PGP signature

To attach a PGP signature on top of the Git commit signature, generate a key and sign the report:

brew install gnupg          # or apt-get install gnupg
gpg --full-generate-key     # RSA 4096, your real name + email
gpg --list-secret-keys --keyid-format LONG
# note the long key id, e.g. 0xDEADBEEFCAFEBABE1234567890ABCDEF

gpg --armor --detach-sign report.html
# creates report.html.asc
# publish report.html and report.html.asc side by side
# publish your PUBLIC key (gpg --armor --export KEYID > report.html.asc.pub) so verifiers can fetch it

Verifiers then run:

gpg --verify report.html.asc report.html

This is recommended when the report is distributed to counterparties (token holders, exchanges, regulators) who want a portable signature independent of GitHub.

7. What to do if verification fails

If the SHA-256s do not match, if the source commit does not match, or if the report file you are looking at is not hosted on the documented GitHub Pages URL — do not deploy. Open an issue or contact the reviewer via the documented channels.

← Home · Report