Feat/pre ipo claim

[razww]

Summary

Adds settlement + claim to PreIPODistributor, on top of the subscription contract. After the whitelist and public rounds close, the manager/bot publish a single settlement merkle root (both rounds combined) through a two-step, time-delayed lifecycle; users then make one permanent claim that pays their USDT refund and either delivers the share token (unlocked tranche) or records the amount for off-chain delivery (locked tranche). The allocation math (weighted pro-rata + cap + waterfall) stays off-chain — the contract only verifies and pays out results committed in the root.

What's added

• Settlement root lifecycle (pending → accept, mirrors LendingRewardsDistributorV2):
  • setSettlementRoot(saleId, root, totalRefund) — BOT, step 1; writes the pending root and starts the review window. Guards: root non-zero/new, no pending already in flight, and totalRefund <= totalDeposits + pubTotalDeposits.
  • finalizeSettlement(saleId) — BOT, step 2; promotes pending → active only after waitingPeriod (min 6h).
  • revokeSettlementRoot(saleId) / setWaitingPeriod(seconds) — MANAGER.
• claim(saleId, account, refundAmount, shareToken, tokenAmount, proof) — permissionless, once per account, permanent. Verifies the leaf, pays the refund, then routes by the on-chain userTranche: unlocked → transfers tokenAmount of shareToken; locked → refund only, amount emitted for off-chain delivery.
• initializeV2() (reinitializer(2)) — sets waitingPeriod = 6h; called at upgrade time so no post-upgrade config is needed.
• New storage (appended over the subscription layout): Settlement struct (root/pendingRoot/pendingTotalRefund/totalRefund/lastSetTime/refunded), settlements, claimed, waitingPeriod.

Design decisions

• One combined root, one claim per account — the leaf carries each account's two-round totals, so users claim once.
• shareToken is in the leaf — leaf = keccak256(abi.encode(chainid, saleId, account, refundAmount, shareToken, tokenAmount)) — so no separate setShareToken step; the address is locked by the finalized root. Delivery mode is still routed by the on-chain userTranche (set at deposit).
• Unlocked tranche requires shareToken != 0 — a zero share token is only valid for the locked tranche; otherwise claim reverts with a clear error instead of a cryptic transfer failure.
• Refund accounting — totalRefund is the committed total (constant after finalize); refunded accumulates per claim, so outstanding = totalRefund - refunded is readable on-chain.
• No withdrawProceeds — proceeds are withdrawn via the existing emergencyWithdraw (MANAGER), which already covers this; the settlement guard keeps a published root from over-committing refunds.
• Roles — BOT drives the root lifecycle (automatable); MANAGER handles revoke/config/emergency; BOT's role-admin is MANAGER (granted at base init, so this upgrade needs no role setup).

Upgrade

UUPS; storage strictly appended over the subscription contract. Apply with upgradeToAndCall(newImpl, abi.encodeCall(PreIPODistributor.initializeV2, ())) so waitingPeriod is initialized atomically with the upgrade.

Testing

forge test --match-contract PreIPODistributorTest

[hashdit-bot]

Pull Request Review

This Solidity UUPS upgrade adds BOT-managed, time-delayed Merkle settlement roots and permissionless claims for refunds and share-token allocations. It also introduces settlement state, role administration, configurable review periods, and extensive Foundry tests for the new workflow.

Sensitive Content

No sensitive content detected.

Security Issues

🟠 [HIGH] Declared refund total is not enforced during claims

File: contracts/dao/PreIPODistributor.sol
setSettlementRoot limits the declared _totalRefund to the sale’s deposits, but claim never checks that s.refunded + _refundAmount <= s.totalRefund. Consequently, a malformed settlement tree can commit leaves whose aggregate refunds exceed both the declared total and the sale’s deposits. Because contract balances are pooled and additional roots can be finalized for the same sale while refunded remains cumulative, claims may consume funds belonging to other sales.
Recommendation: Before transferring a refund, require _refundAmount <= s.totalRefund - s.refunded, and ensure finalizing a replacement root cannot set totalRefund below amounts already refunded. If settlements are intended to be permanent, disallow setting another root after one has been finalized; otherwise define and enforce a cumulative replacement-root accounting model.

---

Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits.

[hashdit-bot]

Pull Request Review

This Solidity/UUPS upgrade adds a two-step, role-controlled settlement Merkle root lifecycle and permissionless claims for deposit refunds and share-token delivery. It appends settlement accounting storage, initializes a six-hour review period, and adds Foundry tests covering settlement, claims, roles, and initialization.

Sensitive Content

No sensitive content detected.

Security Issues

🟠 [HIGH] Claims are not bounded by the committed total refund

File: contracts/dao/PreIPODistributor.sol
setSettlementRoot validates only the declared _totalRefund, but claim never verifies that s.refunded + _refundAmount <= s.totalRefund. A malformed or malicious Merkle tree can therefore contain refund leaves whose aggregate exceeds the reviewed commitment, allowing valid claimants to drain deposit-token balances, including funds associated with other sales using the same token.
Recommendation: Before updating s.refunded, require _refundAmount <= s.totalRefund - s.refunded. Also test that claims whose cumulative refunds exceed totalRefund revert.

🟠 [HIGH] Finalized settlements can be replaced and refund commitments reused

File: contracts/dao/PreIPODistributor.sol
After a root is finalized, setSettlementRoot permits another root for the same sale and finalizeSettlement overwrites root and totalRefund without resetting or reconciling refunded. This violates the stated single-settlement design, permits multiple independently capped roots to pay different accounts from the same deposits, and can permanently prevent accounts that claimed under an earlier root from receiving corrected allocations because claimed is never versioned.
Recommendation: If settlement is intended to be permanent, reject setSettlementRoot once s.root is nonzero. If revisions are required, introduce explicit settlement versions, version the claimed/refund accounting, and enforce a cumulative refund liability that can never exceed the sale’s deposits.

---

Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits.

[qingyang-lista]

LGTM

[qingyang-lista]

LGTM

[hashdit-bot]

Pull Request Review

This Solidity/UUPS upgrade adds a two-step, time-delayed Merkle settlement lifecycle and permissionless one-time claims for refunds and share-token allocations. It appends settlement storage, introduces initializeV2() and waiting-period management, and adds comprehensive Foundry tests for authorization, finalization, revocation, and claim behavior.

Sensitive Content

No sensitive content detected.

Security Issues

No serious security issues detected.

---

Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits.

[hashdit-bot]

Pull Request Review

This Solidity UUPS upgrade adds a two-step, time-delayed Merkle settlement lifecycle and permissionless, single-use claims for refunds and share-token delivery. It appends settlement storage, introduces initializeV2, adds public-round settlement guards and claim previews, and expands Foundry tests and audit documentation.

Sensitive Content

No sensitive content detected.

Security Issues

No serious security issues detected.

---

Generated by Hashdit Bot. This tool can absolutely NOT replace manual audits.

[qingyang-lista]

LGTM