Audit Report — RefundableProductEscrow.sol v0.3.0.3

1. Scope & independence

System under review. contracts/RefundableProductEscrow.sol in mustcompany/must-pirateship at commit 89018f0ee3b04538a7baab4cc58e7d03325bf7f4 ("v0.3.0.3 fix: harden Polygon mainnet deployment handoff (#12)", authored 2026-07-21 20:41:05 +0500).

Target network. Polygon PoS mainnet.

Compiler. solc 0.8.30+commit.73712a01.Darwin.appleclang (universal macOS build, x86_64+arm64), optimizer enabled, 200 runs, EVM target paris, metadata hash ipfs.

Documented deployment parameters (used to derive the deployment initcode):

• beneficiary = 0xcF9178cA7360066B25de9c142A4c155abf151D6f
• minimumPledge = 300000000000000000000 wei (300 × 10¹⁸)

Scope. Single .sol file (197 lines, 7064 bytes, MIT license, pragma ^0.8.24), one contract, no imports, no dependencies.

Out of scope. Off-chain owner and beneficiary identity, frontend, deployment transaction envelope and gas, Polygon sequencer/finality/reorg assumptions, regulator and tax treatment.

Independence & conflict disclosure. I, Mohsin Zahid, have no financial, contractual, employment, equity, advisory, or other relationship with mustcompany, with the must-pirateship project, or with any token, product, or entity referenced by the system under review. I am a member of the public reviewing this code at my own initiative. I was not paid for this report. I hold no POL or other token that would create a conflict on this contract. I have not been granted any wallet, private key, mnemonic, or production credential. No deployment was performed; no on-chain state was touched. The technical analysis was performed by reading the source and compiling it locally with solc 0.8.30 on my own machine; reproduction commands are in VERIFY.html.

2. Fingerprints & deployment initcode

All hashes below were produced by compiling the exact source at commit 89018f0 with solc 0.8.30+commit.73712a01, optimizer enabled at 200 runs, EVM target paris, metadata hash ipfs. The standard-JSON input used is reproduced in VERIFY.html.

2.1 Constructor-bound deployment initcode

The on-chain transaction input that would be sent to a CREATE/CREATE2 factory when deploying this contract with the documented parameters is the creation bytecode concatenated with the ABI-encoded constructor arguments.

Constructor args (ABI types (address, uint256), 64 bytes):

000000000000000000000000cf9178ca7360066b25de9c142a4c155abf151d6f
00000000000000000000000000000000000000000000001043561a8829300000

Head of initcode (solc-emitted deploy prelude):

610100604052600160075534801561001657600080fd5b5060405161138038038061138083398101…

Tail of initcode (last 160 hex chars — CBOR metadata trailer followed by appended constructor args):

a097d6cf9664736f6c634300081e0033000000000000000000000000cf9178ca7360066b25de9c142a4c155abf151d6f
00000000000000000000000000000000000000000000001043561a8829300000

Any party deploying this contract should be able to take the on-chain tx.input from the deployment transaction, strip the last 64 bytes, verify the leading 4992 bytes hash to 9a2fdeed…, and verify the trailing 64 bytes hash to c53eec2…. A mismatch means the on-chain artifact is not the one this report covers.

3. System summary

A native-POL escrow for a single product pre-order:

• A 30-day funding window opens at deployment.
• Supporters send native POL via contribute() or the receive() fallback. First contribution per supporter must be ≥ minimumPledge; later top-ups have no minimum.
• The owner calls markProductReleased(string proofURI) before the deadline to declare the product shipped; a non-empty proofURI is required.
• After release, each individual supporter calls approveProduct() to make their own pledge withdrawable to the immutable beneficiary.
• The beneficiary calls withdrawApprovedFunds() to pull only the sum of approved pledges.
• If the deadline passes without release, or a supporter never approves, the pledge is reclaimable after the deadline via claimRefund() (self) or processRefund(addr) (anyone — funds always go to the original supporter, never to the caller processing the refund).
• Reentrancy on withdrawApprovedFunds and _processRefund is blocked by the nonReentrant modifier using a single uint256 locked flag.

4. Path-by-path review (value-moving & deadline-boundary)

4.1 constructor(address,uint256) (L77–L84)

Pre: beneficiary != 0, minimumPledge != 0. State: four immutables + owner. Value movement: none. Any POL attached to the deployment transaction's value field would sit in the contract permanently with no admin sweep — the contract has no withdraw() for the owner and no selfdestruct.

4.2 receive() / contribute() (L86–L107)

Pre: msg.value > 0, block.timestamp < deadline, !productReleased, supporter not approved, not refunded, and (no prior contribution or first contribution ≥ minimum). State: supporters[msg.sender].amount += msg.value, totalPledged += msg.value, ContributionReceived. Value movement: caller → contract. A supporter who first met the minimum may later top up with any amount, including sub-minimum — this is the design intent.

4.3 markProductReleased(string) (L110–L120, onlyOwner)

Pre: block.timestamp < deadline, !productReleased, non-empty proofURI. State: productReleased = true, releasedAt, productReleaseProof, ProductReleased. Value movement: none. The owner unilaterally transitions Funding → Released; there is no multisig, timelock, or community veto.

4.4 approveProduct() (L123–L137)

Pre: block.timestamp < deadline, productReleased, supporter has amount > 0, not approved, not refunded. State: approved = true, totalApproved += amount, withdrawableApproved += amount, ProductApproved. Value movement: none at this call. The pledge is marked withdrawable; the actual transfer to the beneficiary is gated on withdrawApprovedFunds. Approval is permanent — there is no disapproveProduct(). The strict block.timestamp < deadline check means a supporter has until deadline - 1 to approve; there is no grace period.

4.5 withdrawApprovedFunds() (L151–L161, nonReentrant)

Pre: msg.sender == beneficiary, withdrawableApproved > 0. State: withdrawableApproved = 0 (before the external call), POL call{value:} to beneficiary, ApprovedFundsWithdrawn. Value movement: contract → beneficiary. Checks-effects-interactions ordering is correct. The nonReentrant guard prevents re-entry into either withdrawApprovedFunds or _processRefund from a beneficiary that reenters. This is the only path by which POL leaves the contract to the beneficiary.

4.6 claimRefund() / processRefund(address) → _processRefund (L140–L148, L180–L196, nonReentrant)

Pre: block.timestamp >= deadline, supporter has amount > 0, not approved, not refunded. State: refunded = true, totalRefunded += amount, POL call{value:} to the supporter (not the caller), RefundProcessed. Value movement: contract → supporter. Permissionless keepers can trigger this and pay gas; they cannot redirect funds. A failed send (e.g. supporter contract whose fallback always reverts) reverts the whole transaction; the refunded flag rolls back so the next caller can retry. There is no "skip and move on" path; a single broken-supporter contract can grief a batched keeper transaction — a keeper should refund one address per tx.

4.7 View helpers

phase() correctly maps deadline ≤ now → Refunds; else Released/Funding. isKeyEligible(address) returns record.amount >= minimumPledge && approved && !refunded. refundableAmount(address) returns 0 if the campaign is still active, the supporter approved, or the supporter already refunded; otherwise record.amount. All three are pure reads.

5. Findings

5.1 Medium

5.2 Low

6. Residual risks (non-source)

• R-1. Deployment-time misconfiguration. M-3 in operational form. The reported on-chain addresses and parameters should be re-checked against the dealized spec before broadcasting.
• R-2. Owner key compromise. The owner is a single EOA (or whatever contract the deployer uses) and gates markProductReleased. A compromised owner can mark release without shipping, causing supporters to either approve a non-existent product (loss of refund right) or not approve and reclaim at deadline. The blast radius is bounded (the contract is non-custodial) but the trust assumption is real. Recommendation: owner is a multisig and a public identity.
• R-3. Beneficiary key compromise. Similar to R-2 for the withdrawal side. Loss is capped at the sum of pledges whose supporters approved. Recommendation: beneficiary is a multisig, ideally coordinated with the owner.
• R-4. Off-chain proofURI content. The contract does not validate the proofURI scheme, length cap (besides non-empty), or content hash. A malicious or compromised owner can set any string. Mitigation is off-chain (frontend display, public reasoning). Not a contract defect.
• R-5. Polygon's sequencer / finality assumptions. Out of scope of a source-only review.

7. Deployment verdict

Conditions of approval:

1. The deployer confirms the on-chain owner is the intended address.
2. The deployer confirms value == 0 on the deployment transaction.
3. The owner and beneficiary operate as disclosed multisigs, with the beneficiary publicly known.
4. A frontend explains the permanence of approveProduct() to supporters.

Rationale. No high-severity source issues. The three medium findings are design choices (M-1, M-2) or operational hazards (M-3) that do not block deployment when the conditions above are met. All value-moving paths are guarded by nonReentrant with correct CEI ordering. All access paths are gated by the right role. All deadline boundaries are consistent. Immutables match the documented deployment parameters. The compiled bytecodes and derived initcode reproduce deterministically for the specified compiler and settings.

8. Reviewer signature & verification