Pre-seed raise
Pre-seed angels participate via off-chain SAFT (Simple Agreement for Future Tokens), depositing stablecoin to a 2-of-3 multisig receiving wallet. Token allocations and vesting schedule are committed in the SAFT now; the on-chain SAFT contract (SunimaRaiseV2, audit-frozen Sepolia reference below) is deployed to mainnet at round close and loaded with the same allocations — at which point investors claim their tokens directly on-chain by the published vesting curve. 5 % TGE unlock, 95 % linear over 3 years.
How the pre-seed round runs now
The pre-seed is operated off-chain because the on-chain SAFT contract is audit-frozen but not yet deployed to mainnet (it lives on Arbitrum Sepolia as a reference implementation, see below). Angels participate by signing a written SAFT and depositing stablecoin to a published multisig receiving wallet.
Signal interest
Reach out directly (DM or [email protected]). We share the SAFT template, the allocation worksheet, and the current FDV / token price. No KYC at this stage for crypto-native participants; standard KYC required for any participant requesting a fiat receipt.
Sign the SAFT (off-chain)
The SAFT is a written agreement specifying: deposit amount in stablecoin, token allocation in $SUNA (computed at the agreed FDV), vesting schedule (5 % TGE unlock, 95 % linear over 3 years from mainnet TGE), and the conversion clause that triggers on-chain claim against the deployed SunimaRaise contract.
Deposit to receiving multisig
Stablecoin (USDC) goes to a 2-of-3 Gnosis Safe receiving wallet on Arbitrum. Address is published here once the Safe is constructed. Deposit transactions are public on-chain by design — investors can verify the wallet balance and the founder cannot drain in a single signature.
SAFT countersigned, allocation recorded
Once the deposit lands the SAFT is countersigned and the investor's allocation is recorded in the round ledger. The ledger is the input that gets loaded on-chain at mainnet deploy.
On-chain conversion at mainnet deploy
When the round closes (target reached or deposit window ends), SunimaRaise is deployed to Arbitrum mainnet, the round is created with the collected allocations, and vesting tokens are escrowed. From this point investors claim tokens directly on-chain per the published vesting curve — see the on-chain flow section below for details.
SunimaRaiseV2 — testnet reference
Live on Arbitrum Sepolia, source-verified via Sourcify, ABI public. The Sepolia deployment is the audit-frozen reference implementation. Real angel deposits will be processed through the mainnet deployment when the round opens.
Deployment record
0x809Dcbd660552FF4CAf67B7C9590c432A337e0d3
Arbitrum Sepolia · chainId 421614
founder EOA (only owner can createRound)
75 bps (0.75 %) · snapshotted per round at create-time
What the contract guarantees
Every property below is enforced by code (not by off-chain agreement) and exercised by the test suite. Each closes a real audit-discovered failure class — the iteration history is published in the project session log.
Per-round escrow isolation
Stablecoin deposits live in roundStableBalance[rid]. Vesting tokens live in roundTokenBalance[rid]. A founder cannot drain another round's pool by misconfiguring vesting tokens or stablecoin selection — cross-role token classification is O(1)-checked at createRound and fundVesting.
Bps-accumulator refund
Every investor's refund entitlement is computed independently as myDeposit × (failedBps + cancelBonusBps − claimedBps) / 10000. There is no shared shrinking pool — the order in which investors refund cannot reduce another investor's payout.
Vesting before release
Founder cannot claim the upfront tranche or trigger the close tranche until fundVesting has escrowed the full totalDeposited × tokensPerStable / 1e18 token amount. Standard SAFT escrow pattern, enforced by code.
Founder excluded from multisig
Round creation rejects any signer set where the founder address appears, and rejects duplicate or zero-address signers. The 2-of-3 close-tranche confirmation threshold is therefore always 2 non-founder signatures — no "founder-plus-one" collapse.
Tranche-scaled token claim
Tokens claimable by an investor are scaled by the released-bps fraction. After the upfront release the investor can claim their upfront share; after the close release the remainder becomes claimable. If the round is cancelled before fundVesting, deposits refund fully and no tokens are released.
Pull-based fees
Platform fees accrue to feeAccrued[token][recipient] on each release; the recipient pulls them via withdrawFee(). A blacklisted or reverting fee recipient cannot brick founder releases — accrual is push-free.
Rate immutability
The vesting token address and per-stablecoin token rate are committed at createRound and cannot be changed. Investors deposit knowing exactly how many $SUNA each unit of stablecoin will vest into; founder cannot pick a punitive rate post-deposit.
Reentrancy + FOT-safe deposits
Every fund-moving function carries nonReentrant. Deposit credits the post-transfer balance delta (FOT-token-safe) and rejects sub-minimum receipts after fee. Vesting funding requires strict equality — fee-on-transfer vesting tokens are explicitly rejected.
How the on-chain SAFT will work after deploy
Once the receiving wallet has collected pre-seed deposits and the round closes, SunimaRaiseV2 (or its V3 successor) is deployed to Arbitrum mainnet with the same allocations loaded on-chain. Investors then claim their tokens directly from the contract by the published vesting curve. The flow below describes that on-chain phase — not the current off-chain deposit step.
Round creation
Owner calls createRound with the upfront and close tranche split committed at creation, and three non-founder signers. The vesting token address and tokensPerStable rate are immutable from here; the exact split per round is published in the per-round SAFT.
Deposit window
Investors call deposit(roundId, amount). Contract credits the actual received delta (FOT-safe). Deposits are blocked once block.timestamp > depositDeadline or the round target is reached.
Vesting escrow (founder)
After depositDeadline closes, the founder calls fundVesting(roundId), escrowing exactly totalDeposited × tokensPerStable / 1e18 vesting tokens. No release of any kind is possible before this step.
Upfront tranche
Founder calls claimUpfront(roundId) once vesting is funded. Receives totalDeposited × upfrontBps × (10000 − feeBps) / 10000². Fee accrues to feeAccrued for later pull.
Close tranche
Two of the three non-founder signers call confirmMilestone(roundId, 0) after the close deadline passes. On reaching the 2-of-3 threshold the contract releases the remaining stablecoin to the founder. This is the formal round-close step; signers confirm the round actually ran (deposits collected, vesting escrowed) before the final tranche flows.
Cancellation refund (only before fundVesting)
If the round is cancelled before fundVesting, each investor calls refund(roundId) to recover their full deposit independently. After fundVesting + claimUpfront the upfront tranche is no longer recoverable — investor protection past this point lives in the irrevocably escrowed vesting tokens, not in a refund pool.
Token claim (vesting)
Investors call claimTokens(roundId) at any point after fundVesting. They receive tokens scaled by released bps — the upfront share becomes claimable after the upfront release, the remainder after the close tranche confirms. Vesting tokens stay irrevocably escrowed in the contract from fundVesting onward; no founder action can revoke them.
Founder reclaim (cancelled rounds only)
If the round is cancelled and the close tranche never confirms, the founder calls reclaimVesting(roundId) once to recover the vesting portion that won't be paid out. On a fully released round (both tranches confirmed) no reclaim is needed — 100 % of vesting tokens flow to investors.
What this contract is not
Read this carefully before assuming the testnet deployment is the active investment vehicle.
The Sepolia deployment does not accept real deposits
Arbitrum Sepolia is a testnet. The $SUNA balance held by the on-chain contract is testnet-only. Interacting with the Sepolia address creates no financial obligation either way — it is published as the audit-frozen reference implementation, so the design can be inspected and replayed before a single dollar is sent to the receiving wallet. Real angel deposits go to the off-chain receiving multisig (see flow above); the mainnet on-chain contract is deployed when the round closes.
Pre-seed is off-chain SAFT first, on-chain after the round closes
Pre-seed angels deposit stablecoin to a 2-of-3 receiving multisig and sign a written SAFT specifying allocation and vesting. This is the standard angel-round pattern. The on-chain SunimaRaise contract is the conversion layer: at mainnet deploy the round is created with the same allocations on-chain, vesting tokens are escrowed, and investors claim directly from the contract. The off-chain phase is transitional; from mainnet deploy onward, the on-chain flow is canonical.
Owner-gated round creation
The Sepolia deployment is single-org operation: only the contract owner (founder EOA) can call createRound. This is intentional for the pre-seed use case. Multi-tenant deployment (multiple unrelated raisers on the same contract) requires additional gating — a creation bond, role-binding, or a per-tenant variant — and is not in scope for the pre-seed round.
No external audit yet — only internal cold-eye + automated test suite
The internal audit gate (RAG-pattern adversarial audit + independent multi-model LLM cold-eye zero-context review) passed through 9 iterations. External audit (Code4rena / Cantina / Spearbit) is part of the mainnet deploy plan, not a current claim. Until external audit lands, the design's trustworthiness is bounded by the published source plus the audit iteration log.
9 cold-eye iterations to a clean internal review
Each iteration was a zero-context cold-read augmented with 50-vector RAG retrieval against a 58 468-point indexed corpus of historical Solidity attack vectors (Solodit, Code4rena, Cyfrin, DefiHackLabs, Trail of Bits, Pashov, Spearbit, OpenZeppelin, ConsenSys, REKT, Crytic). Each non-INFO finding was triaged, fixed in source, re-tested, then re-audited in the next iteration. Summary:
Original draft
1 CRITICAL + 4 HIGH + 5 MEDIUM in pre-existing SunimaRaise.sol (March 2026 draft, never deployed). Cross-round drain via setTokenVesting; refund pool drained by single milestone failure; FOT-token deposit credit inflation; founder-equals-signer collapse.
Initial v2 architecture
1 CRITICAL + 1 HIGH + 1 MEDIUM: failMilestone post-cancel double-counted bps; claimTokens after cancel allowed double-dip; fundVesting O(N) loop griefable.
Deposit-window timing
2 HIGH + 2 MEDIUM: confirmMilestone and fundVesting before deposit-deadline stranded funds (totalDeposited mid-stream).
Vesting trust + fee recipient
1 HIGH + 1 MEDIUM: founder could collect milestones without ever funding vesting (ghost-walk); reverting feeRecipient bricks all releases.
Cancel-mid-flight + ownership
1 HIGH + 1 MEDIUM: multisig cancel mid-flight gave investors free vesting tokens; founder couldn't reclaim escrow on cancel.
Partial-claim accounting
1 HIGH + 1 MEDIUM: tokensClaimed boolean stranded partial claims; createRound permissionless namespace squat.
Reclaim repeatability
1 CRITICAL: reclaimVesting was repeatedly callable; second call drained investor entitlement. One-shot guard added.
Founder-chosen rate timing
1 MEDIUM: tokensPerStable chosen by founder after deposit close. Rate now committed at createRound (immutable).
Fee push vs pull
1 MEDIUM: blacklisted feeRecipient bricks releases. Pull-based fee accrual added.
Clean internal review
0 ≥ MEDIUM. Tail: 3 LOW + 1 INFO non-blocking (single-step ownership, dust precision, doc clarifications) — collected for v2.1 batch.