Assumptions
Security model and practical limits
Clear boundary between what contracts guarantee and what still depends on user coordination.
1. Security assumptions
- Participant funds are held by contract logic, not a single operator wallet.
- Acquisition and sale actions are gated by state and quorum checks.
- Proposal tuple checks prevent parameter drift between voting and execution.
- Transfer accounting rejects unsupported token mechanics that break invariants.
- Onchain events provide auditability for deposits, votes, and execution outcomes.
2. What contracts do not guarantee
- OTC seller behavior offchain is not enforced by protocol until execution transaction.
- NFT approval and ownership can change before buy execution and cause revert.
- Testnet liquidity, price discovery, and external market depth are not guaranteed.
- Frontend forks or spoofed domains can mislead users if URLs are not verified.
3. Known limitations
| Area | Limitation | Operational impact |
|---|
| Faucet | Per-wallet cooldown + finite faucet liquidity | Users may need wait period or operator top-up |
| Token support | Fee/rebase or non-standard transfer tokens are rejected | Only standard ERC20 behavior is accepted |
| Pause behavior | Most operational paths are pause-guarded | Execution flow can be frozen by admin action |
| Refund path | `withdrawRefund` remains available after failed funding even during pause | Participants can still exit failed fundraise safely |
| NFT transfer preconditions | Seller must still own token and approve transfer at execution time | Acquisition may revert if preconditions changed |