Please report vulnerabilities privately through GitHub's "Report a vulnerability" form on this repository, not in public issues.

Base's sequencer orders transactions and sets timestamps. Deadlines are whole days, so timestamp drift has no practical effect. If the chain is unavailable for the whole settlement window, the campaign falls back to the full refund.

• Code: src/MorcastEscrow.sol, src/libraries/SettlementMath.sol, src/interfaces/IMorcastEscrow.sol.
• Manual review: access control, the status machine, reentrancy and call ordering, arithmetic and rounding, Merkle proofs and leaf encoding, token behaviour, deadlines, isolation between campaigns, owner powers, and denial of service.
• Static analysis:
  • Slither 0.11.6 (all detectors), Aderyn 0.6.8 and the Foundry linter
  • Solidity 0.8.37 has no known compiler bugs
  • no OpenZeppelin Contracts advisory affects the modules used (Ownable2Step, SafeERC20, MerkleProof, Math, ReentrancyGuardTransient).
• Tests:
  • unit tests with 100% line coverage, and fuzz tests
  • invariant tests: 51,200 random calls per CI run, including every owner action
  • Base mainnet fork tests with the real USDC and MOR
  • the local end-to-end run
  • the attack scenarios in test/Security.t.sol.

For every campaign inside its settlement window, a compromised or dishonest settler can choose any recognized total (up to spending the whole budget) and any Merkle root. That sends up to the creator pool, 80% of the budget, to wallets of its choice. The fee still goes to the treasury and the refund to the brand.

The owner can appoint the settler, so a compromised owner has the same reach. In addition, it can void funded campaigns (their budgets go back to the brands) and redirect future fee withdrawals. Neither role can take escrowed funds in any other way. This is the protocol's trust model, with Morcast as the single trusted verifier.

Mitigations:

• Keep the owner and the settler in separate wallets, with their keys on hardware signers.
• Settle only from a published dataset that passes morcast-verify.
• Monitor every CampaignSettled event against the published datasets, and every owner event (SettlerUpdated, TreasuryUpdated, CampaignTokenUpdated, CreationPausedUpdated, CampaignVoided, TokensRecovered, ownership transfers).

createCampaign accepted any startAt < endAt. Once startAt has passed, the brand cannot cancel, and an unsettled budget returns only from endAt + 10 days. A mistaken endAt, for example milliseconds instead of seconds, would have locked the budget for thousands of years.

Fixed. createCampaign rejects campaigns longer than MAX_CAMPAIGN_DURATION (90 days), so a mistaken endAt fails at creation. A lead time before startAt needs no limit, because the brand can cancel at any time before the start. The owner can also void a campaign created by mistake.

If Circle pauses USDC, every USDC campaign is blocked until the pause ends. A blacklisted creator, brand or treasury cannot receive its payout. A blacklisted escrow would freeze all USDC campaigns. There is no path to reassign a payout. MOR is not affected.

The contract checks proofs, not the contents of the tree. If the leaves add up to less than the pool, or pay an address that can never receive (the zero address or the escrow itself), the difference stays locked, because settlement is final.

Mitigations:

• The SDK refuses zero-address payouts.
• The verifier rejects creator wallets equal to the zero address or the escrow.
• The platform must verify the dataset before calling settle.

Leaves that add up to more than the pool are harmless, because claims stop at the pool.

Tokens transferred to the escrow other than through createCampaign could not be withdrawn. They never affected any campaign's accounting.

Fixed. The escrow tracks totalOwed per token, and the owner's recoverTokens returns only the balance above it. Campaign funds cannot be recovered.

The reentrancy guard uses EIP-1153 transient storage. Deploy only to chains with the Cancun instruction set. Base supports it, and the fork tests run there.

Concurrent createCampaign transactions can change which ID a campaign receives. Off-chain systems must read the ID from the CampaignCreated event of the brand's transaction, not predict it.

The owner can void a funded campaign at any time, including after creators have posted their content. The budget goes back to the brand only, so nothing can be stolen, but creators lose the payout they were working toward. Voiding must follow Morcast's published policy, for example for a mistaken deposit, a cancellation agreed with the brand before creators start, or an emergency.